[llvm-dev] Problem with "[SimplifyCFG] Handle tail-sinking of more than 2 incoming branches"
Marcello Maggioni via llvm-dev
llvm-dev at lists.llvm.org
Sat Sep 3 11:10:00 PDT 2016
You guys make a good point in talking about using an intrinsic for this.
It is not probably easy switching to using an intrinsic though, because it is difficult to quantify exactly how much of the compiler relies on the fact that this kind of loads are actually loads and not some other kind of intrinsic.
Thanks for the suggestion though, I’ll certainly make sure to explore that option!
> On 3 Sep 2016, at 03:13, James Molloy via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 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 :)
>> 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.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev