Two nits inlined. Otherwise this patch looks OK, eyeballing the supplied test.
Mar 26 2020
Mar 20 2020
Some post commit remarks.
Aug 28 2019
Aug 21 2019
What difference does SYM_32/SYM_64 make, all selected instructions use only 16 bits of something that is resolved later?
Thanks for review. Could you clarify some points in your comments?
The correct approach I believe is to fix the SYM_32 bug, then provide the patterns for cases of where intermediate/end nodes such as MipsHi / MipsLo can appear without an add appearing as their parent node.
- If we do not change the getAddrNonPICSym64 function, at some point (before lowering) we anyway(?) get the following chain of commands (add (shl (%hi(sym), 16), %lo(%sym)). How can we lower it to a correct set of instructions, if we do not have a pattern with the shl? Please correct we if I'm wrong.
Aug 15 2019
I took a second look, and I believe this patch is the incorrect solution. The bug actually lies in the implementation of PredicateControl and SYM_32/SYM_64, @Petar.Avramovic nearly spotted it.
Aug 14 2019
This looks OK to me, I'd like to take a hard look at what DAGCombiner is doing here.
Jun 26 2019
May 23 2019
May 21 2019
I've raised some points inline, I think (a) is most relevant to this patch but shouldn't stop it going forward but should be addressed quickly, (b) and (c) could be noted as TODO:s.
Apr 26 2019
Is there a specific version range of GCC that this miscompile occurs with?
Mar 28 2019
I think this is a viable approach for this issue. Based on the dumps from -debug I can see that the backend should only be selecting even register for FGR32.
Mar 26 2019
My initial comments are that this looks ok, but I would like a longer look at it.
Mar 21 2019
Mar 7 2019
One nit inline, but otherwise LGTM.
Mar 6 2019
Some minor nits inlined, but otherwise the patch is more or less there.
Feb 28 2019
Two comments, and some more inlined. Check the formatting of the commit message
body, it should be 80 cols max. Otherwise the log messages can look strange due
to wrapping (I'm using git).
Feb 23 2019
Feb 21 2019
Sorry I didn't spot this earlier, but in future please ensure 'llvm-commits' is one of the subscribers when creating a review request for LLVM. If you add it after creating a review request, manually add it and write something in the comments field to trigger Phabricator into sending an email or abandon the review request and re-open it with the relevant -commits list as an initial subscriber.
LGTM apart from some minor nits. Please address them before committing.
Feb 13 2019
Any testcases that can show the problem and test the fix? Thanks.
It can only be triggered by a very large (>32KB) function body because the range of conditional branch is +/- 32KB.
In our case, the large function body is caused by aggressive thinlto guided inlining.
So no small test case can demonstrate the problem :(
Jan 18 2019
Dec 19 2018
I can't find rationale behind the MIPS discrepancy in the original commit. I can add the if branch back if you tell me why...
Oct 29 2018
LGTM. Just remember to upload the patches with context.
Oct 22 2018
Sep 10 2018
Aug 30 2018
Jul 6 2018
Jun 27 2018
Jun 22 2018
Jun 21 2018
Jun 20 2018
Jun 19 2018
Looking at this again and with trunk, I'm seeing two failing tests with a small change inlined:
Added tests, and corrected the definition of the rdhwr instruction.
Jun 18 2018
Jun 15 2018
Jun 14 2018
Jun 13 2018
Actually include the expansion pass.
Moved pass to after the scheduler and machine block placement.
Normalized the probabilities for the successors of modified basic blocks for sanity purposes.
Jun 12 2018
Is this something which is actually useful to control? From your description, you want to add the flag to clang not because you actually want to use it, but just because you can't figure out how to pass the right flags to your clang build.
If it is useful, it should be implemented as a function attribute, not a global flag.
Modify implementation to produce a function attribute.
Jun 11 2018
LGTM with nit addressed.
Rebase to master.
In D48006, you can see the change for the MIPS specific assembly scrubbing to accept inline assembly. I have also included some example output of the changes of that revision. Since the blank lines around the inline assembly are not scrubbed, FileCheck fails the test case with:
Jun 9 2018
Jun 8 2018
Please rebase this.
Actually add some tests.
Edit the summary so that rather that it says:
Jun 7 2018
Jun 6 2018
The legalization of unsigned i128 addition (rL334094 for the test) looks strange to me in that the determination of the overflow from the first addition is done with setccs. They appear to be originating from the expansion of setcc of an illegal type.
This particular case is not quite testable, as GPR64s are only available when we have 64 bit registers. Adding GPR_64 predicates to these instructions is somewhat overkill, but does simplify fixing up the scheduler models later.