[llvm-dev] Improving SCEV's behavior around IR level no-wrap flags
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 23 22:32:48 PDT 2016
Andrew Trick wrote:
>> On Sep 23, 2016, at 7:50 AM, Christof Douma <Christof.Douma at arm.com <mailto:Christof.Douma at arm.com>> wrote:
>> I can’t help to ask. Why not define a wrapping nsw instruction as UB, instead of “delayed UB” aka poison? I believe we
>> have the notion of poison solely to ease the movement of instructions. In my example above line 6 can be moved to line
>> 2 due to poison. If the wrapping was UB such a move is still possible but would require dropping the nsw flag, nothing
>> more. If this information loss is considered a problem, the use of llvm.assume can counter that.
>> Has somebody ever looked at not having poison at all? What are the downsides of that?
> That’s basically incompatible with transformation of the IR. I’m sure that’s been explained by DanG in the past, but I
> don’t have a link. e.g. the optimizer doesn’t think that an ‘add’ has side effects and wants to freely hoist and combine
> these operations. If the operation has an ‘nsw’ flag that would change the UB semantics.
> I have to say, my heart is not really into optimizing for UB. Is this relevant to any scenario other than legacy
> C-without-overflow/bounds checks?
I don't think we'll be able to give up on C and C++ inspired
optimizations anytime soon. Given what I've seen on llvm-dev and
bugzilla, it is pretty clear to me that we have to do _something_ to
address the missing pieces here.
More information about the llvm-dev