[llvm] r331115 - [globalisel][legalizerinfo] Introduce dedicated extending loads and add lowerings for them

Daniel Sanders via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 30 10:24:45 PDT 2018


No worries.

This should be fixed in r331201. The lowering code now catches the case where it has been asked to lower an any-extending load but the load it has been asked to lower is a non-extending load and the target doesn't try to lower vector loads. This causes GlobalISel to fall back on DAGISel like this testcase did before r331115.

> On 30 Apr 2018, at 09:32, David Green <David.Green at arm.com> wrote:
> 
> Thanks!
> 
> And sorry of the legal. I forgot to include the nd needed to communicate civilly. Do please ignore.
> 
> Cheers for looking into the problem,
> Dave.
> 
> 
> From: daniel_l_sanders at apple.com <daniel_l_sanders at apple.com> on behalf of Daniel Sanders <daniel_l_sanders at apple.com>
> Sent: 30 April 2018 17:04
> To: David Green
> Subject: Re: [llvm] r331115 - [globalisel][legalizerinfo] Introduce dedicated extending loads and add lowerings for them
> 
> Hi David,
> 
> Could you re-add the list? I'd normally add it back in but given the notice at the end of your email it would be preferable if you added it just in case it was intentionally removed.
> 
> Thanks for reporting this. The problem seems to be two instructions of the form:
>    %21:_(<4 x s16>) = G_LOAD %5(p0) :: (load 8 from %ir.__ret.i)
> It's lowering this instruction because the MachineMemOperand says it loads 8 bytes but the type is 4 bytes. That shouldn't be a problem by itself, but the lowering code isn't actually changing anything so it just loops forever.
> 
> I'll take a quick look and if the problem isn't obvious I'll revert while I figure it out
> 
>> On 30 Apr 2018, at 07:12, David Green <David.Green at arm.com> wrote:
>> 
>> Hello!
>> 
>> I have what appears to be some stuck code. Compiled with llc -O0 tmp.ll, it gets itself stuck in legalising G_LOAD's. It originally comes from some random neon intrinsic generation tests, but the C reproducer turns out to come from a utility function.
>> 
>> Any ideas?
>> Cheers
>> Dave
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>> <tmp.c><tmp.ll>
> 



More information about the llvm-commits mailing list