[llvm] r280783 - Remove unnecessary call to getAllocatableRegClass

[Matt Arsenault via llvm-commits]

> On Oct 28, 2016, at 13:34, Justin Bogner <mail at justinbogner.com> wrote:
> 
> Matt Arsenault <arsenm2 at gmail.com <mailto:arsenm2 at gmail.com>> writes:
>>> On Oct 27, 2016, at 15:39, Justin Bogner <mail at justinbogner.com> wrote:
>>> 
>>> Quentin Colombet via llvm-commits <llvm-commits at lists.llvm.org> writes:
>>>>> On Sep 30, 2016, at 12:07 PM, Krzysztof Parzyszek via llvm-commits
>>>>> <llvm-commits at lists.llvm.org> wrote:
>>>>> 
>>>>> On 9/30/2016 1:46 PM, Justin Bogner via llvm-commits wrote:
>>>>>> The assert I'm seeing is in the case where `OpRC != nullptr` but
>>>>>> `ConstrainedRC == nullptr`. Quentin's suggestion would call
>>>>>> getAllocatableClass(DstRC) in this case, whereas in the committed code
>>>>>> we just go ahead and do MRI->createVirtualRegister(OpRC). The call to
>>>>>> createVirtualRegister asserts because OpRC isn't allocatable.
>>>>> 
>>>>> This doesn't sound right. This implies that a register was created
>>>>> for the operand that is not compatible with the operand's
>>>>> class. Sounds like the problem is somewhere else.
>>>> 
>>>> That’s exactly what this code is supposed to fix IIRC. Thus, the
>>>> current patch does not sound right :).
>>> 
>>> Ping. Matt, have you had a chance to look at this?
>> 
>> The problem is I want to use the output from constrainRegClass as the
>> virtual register class instead of getAllocatableClass. Instead of the
>> assert in the case where constrainRegClass fails, would it work to try
>> using getAllocatableClass instead? i.e. getAllocatableClass is the
>> fallback if constrainRegClass fails and then the same create vreg and
>> copy
> 
> Do you mean something like this?
> 
> <addregop.patch>

Yes, that works for me. That avoids the original problem of calling it right away on the register class in the instruction definition

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161028/7ce372b1/attachment.html>