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

[ORiordan, Martin via llvm-dev]

Thanks Hal,

I tried using the static analysers and they detect the UB nature of the expression, so the programmer still has that approach for finding this kind of bug at build time rather than run-time.

All the best,

	MartinO


-----Original Message-----
From: Hal Finkel [mailto:hfinkel at anl.gov] 
Sent: Tuesday, October 3, 2017 5:45 PM
To: ORiordan, Martin <martin.oriordan at intel.com>; David Chisnall <David.Chisnall at cl.cam.ac.uk>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Change in optimisation with UB in mind


On 10/03/2017 08:43 AM, ORiordan, Martin via llvm-dev wrote:
> 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.

It might appear to be useful, but I don't think that we want to do down that road. We don't support this kind of trapping arithmetic in LLVM, the way that we define our canonical forms depend on this, and if want to support it, we need to enhance the IR with constructs that represent this in a well-defined way. Having a mode in which it "kind of works most of the time" is worse, in the long run, than just saying that it is not supported. Right now, it is not supported. I think that our experience has shown us that If we don't have a sound set of rules by which we can validate transformations, then no one really knows what they can do.

  -Hal

>
> 	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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--
Hal Finkel
Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory

--------------------------------------------------------------
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.