[PATCH] PR19137: Correct PRE handling of llvm.sadd.with.overflow followed by add.

[Erik Verbruggen]

Ping! But see below...

On 28 Mar 2014, at 17:09, Erik Verbruggen <erik.verbruggen at me.com> wrote:

> You might have seen already that I decided to revert the patches for now to come up with something else than a fix to a fix ;-)
> 
> So tackling the question about the hashing: the problem is that the overflow intrinsics are hashed as call, which means that the function name is added as the third operand. That implies that llvm.sadd.with.overflow.i32(%a, %b) is not the same as llvm.sadd.with.overflow.i32(%b, %a). Now we could handle that separately for the add/mul intrinsic, but that depends on how we look up a "similar but not the same" leading instruction.
> 
> I currently see two ways of finding leading instructions that are similar (specifically add/mul/sub overflow intrinsics) in a way that does not interfere with PRE or equality propagation:
> 1. when processing each instruction, and when no leader is found as an exact match, create a hash for the similar one, and try with that
> 2. hash both similar instructions the same and have them added to the leader table for that hash value (as done with my patch), and change findLeader to ignore leaders with a different type than the original instructions, except for the one call in GVN::processInstruction which can handle it safely.
> 
> I have a preference for option 2, because I think that creating a hash for a similar instruction (specifically: building the Expression) every time an add/sub/mul occurs, is more expensive than hashing them the same once.

I might have to come back to my earlier preference. I implemented case 1. and I have to say that it doesn't look too weird at all. Attached is the WIP patch implementing that "option".

Again: feedback please? Please?

-- Erik.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-When-an-overflow-intrinsic-is-followed-by-a-non-over.patch
Type: application/octet-stream
Size: 16379 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140412/cb44301a/attachment.obj>