- User Since
- Nov 16 2012, 6:02 PM (357 w, 2 d)
Wed, Sep 18
One thought that occurs to me when reviewing this. I think we will assume that F18/flang when it lands in the LLVM project will be an optional thing to build and will be an opt-in project at the start that is off by default. What happens when clang --driver-mode=flang is called and flang has not been built? And where would we put a test for that behaviour? If flang were not to be built, should --driver-mode=flang be unsupported/unrecognised and emit an error message?
Tue, Sep 17
Mon, Sep 16
Thu, Sep 12
Thanks for exploring this direction.
Wed, Sep 11
Tue, Sep 10
(*) Actually, for both cases, we can also have a separate class ID for scalar i1 types (with 8 registers).
Thanks for looking at this (it's been a problem for a long time). Let me suggest a different interface, which I believe will improve generality and reduce code duplication in the register-pressure estimator, and let me know what you think...
Mon, Sep 9
Thu, Sep 5
Fri, Aug 30
Is CGP a "mandatory" pass always expected to be executed before ISel? In other words, can we remove logic from SelectionDAGBuilder when rewriting intrinsics here (simply assert that we no longer find intrinsics that should be eliminated by CGP)?
Thu, Aug 29
The '+32' bit is covered by the added CodeGen/PowerPC/inlineasm-extendedmne.ll test, but I'd really like to see direct encoding tests for all of the instructions. Can you please make sure that they all appear in MC/PowerPC/vsx.s and MC/Disassembler/PowerPC/vsx.txt?
Wed, Aug 28
Mon, Aug 26
Aug 23 2019
If Clang already drops it , that is good, then this patch is totally fine.
Aug 22 2019
As I described, the compare will capture only if the other pointer was captured.
Aug 21 2019
If you compare the same pointer (or derived from the same), you need to capture at least one from them "explicitly" to learn the bits.
I'm missing something here. If I have two pointers (e.g., returned from malloc), and I compare them so I know they're equal, then I've learned that the pointers are equal -- and, thus, if I know all of the bits of one pointer I now know all of the bits of the other pointer. As a result, I can still reconstruct it later using that information.
Now the canonicalizer sorts values in PHI nodes. After a discussion, I have decided not to remove duplicates. Those duplicates could come from some other passes and in my opinion, the canonicalizer should make them stand out instead of removing them.
Aug 20 2019
Aug 19 2019
Aug 17 2019
Aug 16 2019
Aug 13 2019
Clang , and probably other software, emit memcpy where memset would be needed.
TargetTransformInfo, in the title, should say TargetInstrInfo.
Aug 12 2019
LGTM. As @MaskRay says, this shouldn't affect PowerPC, so you can remove the '[PowerPC]' from the title.
Aug 9 2019
I also recommend that you canonicalize PHI nodes. In past experiments looking for fixed points in the optimization pipeline, this came up as a significant issue. The order of the predecessors in the PHI operand lists don't carry any significance, also also sometimes a predecessor can be listed multiple times (always with the same corresponding value). It's probably best to canonicalize those so each predecessor is listed only once and the blocks appear in their natural order.
Aug 8 2019
Aug 7 2019
Local flags should certainly override LIBRARY_PATH.
Aug 5 2019
Aug 4 2019
I think that this looks fine, but it should have some direct tests. Either make an analysis that prints out things and then some lit tests, or, some unit tests.
Aug 3 2019
Thanks for starting on this. Can you go ahead and replace the sroa calls with mem2reg calls for O1 and then see what that does to the performance? That strikes me as a major change, but certainly one that potentially makes sense, so I'd rather we go ahead and test it now before we make decisions about other adjustments.
Aug 2 2019
Aug 1 2019
Is this something that could be fixed in TailDuplication?
Jul 24 2019
Jul 22 2019
It is zero initialized, which you claim but which I failed to validate so far.
Jul 19 2019
Jul 18 2019
Jul 17 2019
Jul 16 2019
Jul 15 2019
Jul 14 2019
Jul 11 2019
Jul 10 2019
Jul 9 2019
Ah, fun with overloaded, legacy command-line options...
Do we have any policies against using clang-only builtins in the codebase?
However, if CMBB is in a loop body, we might get performance degradation.
Jul 8 2019
Can you please upload a patch with full context?
Jul 5 2019
Is this really a PowerPC-specific problem? Do we just want to have a general post-RA cleanup that checks for isMoveImmediate() and does this cleanup?
Do you have any kind of test case? I suppose that you can check the output in a test in test/Analysis/LoopInfo to show the ordering?