- User Since
- Dec 17 2012, 10:03 AM (339 w, 3 h)
Fri, Jun 14
LGTM modulo want @paquette pointed out.
Thu, Jun 13
Wed, Jun 12
Agree, the fix is more important than the performance loss at this point.
Wed, Jun 5
Mon, Jun 3
Thu, May 30
What is the use case for this?
Tue, May 28
Mon, May 27
Nitpicks on the test below.
Fri, May 24
May 16 2019
Please provide us with more details about your idea.
May 14 2019
May 13 2019
did anything like this come up in the past?
Looks good to me, modulo the order in which we check the hints.
May 8 2019
May 3 2019
@Quentin: This has the same common-code change as in D58923, with the added VRM to foldMemoryOperand(). You seemed fine with this change, right?
LGTM. Nitpicks below.
May 2 2019
Apr 29 2019
Apr 22 2019
Apr 18 2019
Could you please update the summary before pushing this?
Apr 16 2019
- Use comma separated list instead of group naming.
Apr 15 2019
The source change looks good to me, but I would like a bit more work on the test itself.
Apr 4 2019
Looks reasonable to me.
Apr 3 2019
Are the dead instructions marked during the detect dead lanes pass or during the rename independent SubReg pass?
The generic changes look sensible to me.
I would just suggest to add a comment on what VRM is for on the modified methods.
Mar 27 2019
Mar 26 2019
Mar 25 2019
Fix seg fault with PHIs
Mar 22 2019
Mar 21 2019
Mar 14 2019
All of this logic for reg_sequence and phi is totally broken for AMDGPU, so I might just end up ripping all of this out eventually.
Mar 13 2019
Landed in r356116.
Prototyped a retry legalization process in D59339.
The problem is that this patch is still needed to access the constant, because the legalization artifacts combiner inserts copies instead of updating the users.
For operands that truly need to be constants that shouldn't be legalized, I don't think G_CONSTANT should be used. This is part of the motivation behind D58232 https://reviews.llvm.org/D58232. In SelectionDAG there is the TargetConstant vs. Constant distinction, but I think that makes less sense here, so weird constants should just never be materialized.
Disclaimer: this is just my opinion and in particular I haven't talked with anybody about constants being place holders. So just see my comment as what they are: an individual throwing ideas :).
Update a mips test that I forgot.
Why wouldn't G_CONSTANT be legalized? This doesn't make any sense to me
Mar 12 2019
- Introduce a different variant of getConstantVRegVal instead of overriding the existing one (after talking to @aditya_nandakumar we decided we may want to have more control on what happens when we call this function).
- Add a few comments.
Mar 11 2019
I'm going to hold on that one for a little longer.
I wonder how SDAG handle constant during legalization, because I was not expecting that we would not issue the constant for the new type period.
I suspect it works because constants are just not materialized via instructions and maybe we should just ignore them during legalization. (If a constant is illegal, at the end of the legalization process, it should have any users, right?)
Mar 8 2019
Looks reasonable to me.
Feb 28 2019
Feb 25 2019
The LiveIntervals for the relevant regunits needs to be removed.