[llvm-dev] Change in optimisation with UB in mind

ORiordan, Martin via llvm-dev
Tue, 03 Oct 2017 13:43:52 -0000

Yes, the hairy-edges of undefined behaviour - UB is UB.

It does mean that given:

  __attribute__((noinline)) int foo(int a, int b) { return a + b; }

  int bar1(int x) { return foo(x, INT_MIN); }
  int bar2(int x) { return x + INT_MIN; }

'bar1' and 'bar2' have different outcomes.

However, I think that the new optimisation is neat and valid and I am not
suggesting that it should be changed, but it would be useful if a target could
override this if they choose to do so.

	MartinO

-----Original Message-----
From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
Chisnall
Sent: Tuesday, October 3, 2017 12:20 PM
To: ORiordan, Martin <martin.oriordan at intel.com>
Cc: Sanjoy Das <sanjoy at playingwithpointers.com>; llvm-dev <llvm-dev
at lists.llvm.org>
Subject: Re: [llvm-dev] Change in optimisation with UB in mind

On 3 Oct 2017, at 11:37, ORiordan, Martin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
> My question is not about the validity of the optimisation - it's
perfectly legitimate - but rather about whether a target can configure their TTI
so as to not perform this optimisation and fall-back to using ADD instead so as
to trigger integer underflow detection.

I don’t believe that this is the correct approach.  You are asking for behaviour
of integer overflow in C to be well-defined as trapping (which is a valid
implementation of undefined behaviour).  In LLVM, this would be represented as
using the overflow-checking add intrinsic followed by a branch to a trap in the
overflow case.  The back end should then lower this to a trapping add
instruction.  Clang already has -ftrapv that implements almost this behaviour.

David

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.