[PATCH] D21041: [GVN] PRE can't hoist loads across calls in general.

[Daniel Berlin via llvm-commits]

On Mon, Jun 6, 2016 at 5:15 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Mon, Jun 6, 2016 at 4:38 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>>
>>
>> On Mon, Jun 6, 2016 at 4:06 PM, Eli Friedman <eli.friedman at gmail.com>
>> wrote:
>>
>>> eli.friedman added a comment.
>>>
>>> It probably doesn't make sense to turn every `call` instruction into an
>>> `invoke` or equivalent; that would cause the size of the IR to explode,
>>
>>
>> I'm going to disagree.  GCC has EH/abnormal "fake" edges to handle these
>> cases, and works much better than LLVM in this regard, and has no such
>> explosion problem on normal C++ code. In fact, it's going to be faster.
>>
>> If we have a modeling problem, we should fix the modeling problem.
>> You can abstract this to the block level.  The block has an EH successor,
>>   That just means in some fashion, the block may go to this EH edge.
>> It does not require you terminate the block at every mayThrow instruction.
>>
>
> Oh... so instead of precisely tracking the CFG inside the block, you just
> approximate and say "this block as a whole can terminate early"?  That
> makes sense, especially for stuff like loop optimization.
>

Yes.
The downside is that it pretty much has to appear as a
successor/predecessor edge to make it just work in infrastructure.

This is probably easily achievable by always creating an empty return block
giving may-throw calls a fake edge to it.



>
> There are some places that want more precise tracking, though;
>

Sure, and if you discover "it super matters whether i can put it here or
not", you can look closer.
But you don't *always* have to look closer.



> I ended up rewriting my patch for DSE to precisely track unwind edges.
> Maybe that isn't common enough to be worth worrying about.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160606/6cb9dd3f/attachment.html>