- User Since
- Nov 16 2012, 6:02 PM (305 w, 14 h)
Is there any compile-time impact? Should we just simplify all instructions at this later point instead of having two passes?
I'm somewhat confused by the motivation. Can you explain why the fact that the operands are commuted causes a problem. In D51995, you just seem to be looping over them anyway.
Mon, Sep 17
disable this fold when comparing noalias ptr with null
Unfortunately, I don't think that we can do this. noalias semantics only provide information about the overlap of memory accesses using the resulting pointers, in the context of other necessary constraints, and does not strongly constrain the pointer values. For example, it might be that:
Tue, Sep 11
Mon, Aug 27
Sat, Aug 25
Does this mean that we can remove that previously-discussed x86 logic in Clang?
Thu, Aug 23
Aug 17 2018
Also, if you know, should this actually be the default behavior for all targets? I'm somewhat surprised if x86 and PPC are special cases.
Interesting. Why? Does this effectively match GCC's behavior?
Aug 16 2018
Another option would be to implement some sort of attribute-based overloading. Then OpenMP can provide its own version of the device-side library function without clashing with system headers.
Aug 15 2018
Aug 14 2018
Aug 13 2018
This code certainly looks cleaner.
The DSE test is fine, and I think that you should keep it, but can you please add a direct AA test (like, e.g., test/Analysis/BasicAA/cs-cs.ll)?
Makes sense to me. Obviously needs some test.
A couple of minor comments, but otherwise, LGTM.
Aug 6 2018
Aug 5 2018
Aug 4 2018
Seems like an interesting idea. What's the motivation for doing this?
Aug 3 2018
... As such, how to fall back when the transformation doesn't happen is almost equally important as what to do next when the transformation happens.
Aug 1 2018
Assuming that @aaron.ballman is still okay with this, I think that we should move forward. @erichkeane, I suspect that fixing the ordering problems, which were often arbitrary before and are still so, is a larger change that we'd want to split out regardless (not to mention the fact that we'd need to decide how to fix them). Erich, is that alright with you?
Jul 31 2018
Jul 30 2018
Jul 19 2018
Jul 16 2018
Jul 15 2018
Jul 14 2018
There's nothing special about debug intrinsics here except that there are a lot of them. The problem, as far as I can tell, is that we're repeatedly using dyn_cast on each instruction and doing multiple redundant tests. Adding yet another redundant test will help having a lot of debug intrinsics makes things incrementally more expensive for all other kinds of intrinsics. Thus, this doesn't seem like the right way to fix this. Instead of testing for IntrinsicInst, and then CallInst (which is always true whenever the IntrinsicInst is true), and then we always test for StoreInst (but we don't use an 'else' so we always do this test even when the IntrinsicInst/CallInst is true (which will include debug intrinsics)).
Jul 13 2018
We have a check in aliasSameBasePointerGEPs to avoid PR32314 (which I'll glibly summarize as: we need to be careful about looking through PHIs so that we don't, without realizing it, end up comparing values from different loop iterations). The fact that this looks back through an unknown number of PHIs makes me concerned that we'll get into a similar situation.
Misc cleanup and try to validate ret attrs instead of disqualifying them all.
Jul 12 2018
Updated to not infer speculatable if there are instructions with non-debug metadata, loads with alignment requirements that we can't independently prove, and for functions with value-constraining return-value attributes.
LGTM (there are a lot of changes here, but given that it produces no changes to existing matching tables, that seems like pretty good test coverage).
Jul 10 2018
I specifically didn't want to do this for the YAML output. The tool consuming the YAML should demangle if it wants. It's hard to go backward, and so if the tool needs to map back to symbols in the program, it needs the mangled name. That having been said:
Jul 9 2018
This version detects and report integers only. If there is interest of merging the tool I can add the functionality for floats as well.
Jul 8 2018
Jul 6 2018
Jul 4 2018
Jul 2 2018
Jul 1 2018
Jun 29 2018
Jun 26 2018
Jun 21 2018
Jun 19 2018
I've not looked at the patch itself, but regarding the general functionality: Nice! I've wanted this for as long as I've been working on LLVM :-)
Jun 15 2018
Seems like a good idea. A couple of questions below.
Jun 14 2018
I don't think this is right. Saying the result is undefined seems like what we intend. We might choose, as an implementation technique, to limit how we take advantage of that undefinedness in certain cases, but the violating the constraint still produces logical inconsistencies that can transfer to other parts of the code, and in general, turn into any other kind of undefined behavior (depending on the structure of the code).
Jun 12 2018
I think that this optimization is going to be very fragile in practice without also handling the case where both sides look like (m-idx). Nevertheless, it's good to make AA changes in minimal small increments. Let's try this single case for now.
I put this on the llvm-dev thread, but to repeat it here: