[llvm-dev] Problem with "[SimplifyCFG] Handle tail-sinking of more than 2 incoming branches"

James Molloy via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 3 03:13:37 PDT 2016


Hi,

Yes, indeed, if you changed these loads into intrinsic loads this problem would go away, because we don’t transform intrinsics for this *exact reason*. There are other intrinsics that must take a constant operand - I’ve been working on a way to determine accurately if this is the case or not but it’s not in mainline yet.

I think having this restriction on the IR is outside LLVM’s model, and it’s likely break elsewhere too. I understand the hardware restriction, I just feel that it could be modelled more accurately in the IR :)

Cheers,

James
> On 3 Sep 2016, at 01:06, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> On 9/2/2016 6:54 PM, Marcello Maggioni via llvm-dev wrote:
>> It’s not about weird restrictions we are adding, it’s about the fact
>> that for that specific address space we cannot dynamically index into
>> the memory.
>>
>> The address needs to be a constant of some sort in the selection (it’s
>> an hardware limitation, there’s nothing we can do about it) and the fact
>> that it is transformed into a PHI makes it not constant anymore.
>
> Could you use an intrinsic for the load?
>
> An optimization could reasonably be expected not to replace a constant input to an intrinsic with a variable, so even if it fails at the moment, it could be addressed.
>
> -Krzysztof
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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.


More information about the llvm-dev mailing list