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

[James Molloy via llvm-dev]

Hi,

On 2 Sep 2016, at 22:40, Marcello Maggioni <mmaggioni at apple.com<mailto:mmaggioni at apple.com>> wrote:

What the optimization is doing is extracting the “getelementptr” , making an instruction out of it, sinking the load and using a PHI to select between the address.
This breaks our selection of this types of loads.

Are you referring to a downstream intrinsic, an upstream intrinsic or are you somehow adding strange restrictions yourself on what a load instruction can and can’t do?

There’s a function canReplaceOperandWithVariable() that this optimisation uses to decide if it’s possible to do this. We use this to avoid making things that must be constant (like your example) variable. Perhaps this is doing something wrong? If you’re adding arbitrary restrictions on what loads can do though that’s never going to go well - I’m sorry but we just don’t support that use case. That’s what intrinsics are for.

> Just a question. Why implementing it in SimplifyCFG and not as a separate pass like JumpThreading or something like that?

Because sinking instructions into successors already exists in SimplifyCFG and has done for years. This is a small modification to make it a bit more clever. SimplifyCFG does lots of this kind of stuff already (switch->lookup table for example).

Cheers,

James
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160902/e98ea900/attachment.html>