llvm dev - Sep 2017 - Change in optimisation with UB in mind

With LLVM v5.0, I found failures in some of the 'gcc.c-torture/execute'
tests due to a change in the optimisation where undefined behaviour is involved.
The tests that fail are the '20040409-[123].c' tests.

The underlying failure is due to the optimisation of the following:

   int test2(int x) { return x + INT_MIN; }

from using an ADD instruction to using an OR instruction.  The optimisation is
entirely valid and will produce the correct result for all correct values of
'x', but it introduces a change for architectures that have support for
detecting integer overflow/underflow (signalling or quiet).

For many systems the execution cost of ADD versus OR is the same, so there is no
real reason to choose one versus the other, and UB is UB either way.  However,
it does impact detection of out-of-range integer arithmetic for systems that
have support for this.

Is there a new trait in the TTI, or a call-back elsewhere that allows the target
to choose whether it wants this optimisation to use an ADD or an OR (possibly in
the cost-models)?  I would generally prefer to use ADD versus OR if the cost of
execution is the same.

Thanks,

    MartinO

--------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170929/abbd93dc/attachment.html>

It isn't just about execution on the target machine -- transforming
the Add to an Or makes it easier to infer that the highest bit of the
result is always set later in the optimization pipeline.  Are the
failing tests unit tests for a C compiler?  If so, I'd say the test
cases are broken, unless they're specifically test that e.g. the
compiler does not crash when compiling code like this.

-- Sanjoy

On Fri, Sep 29, 2017 at 4:34 AM, ORiordan, Martin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> With LLVM v5.0, I found failures in some of the ‘gcc.c-torture/execute’
> tests due to a change in the optimisation where undefined behaviour is
> involved.  The tests that fail are the ‘20040409-[123].c’ tests.
>
>
>
> The underlying failure is due to the optimisation of the following:
>
>
>
>    int test2(int x) { return x + INT_MIN; }
>
>
>
> from using an ADD instruction to using an OR instruction.  The optimisation
> is entirely valid and will produce the correct result for all correct
values
> of ‘x’, but it introduces a change for architectures that have support for
> detecting integer overflow/underflow (signalling or quiet).
>
>
>
> For many systems the execution cost of ADD versus OR is the same, so there
> is no real reason to choose one versus the other, and UB is UB either way.
> However, it does impact detection of out-of-range integer arithmetic for
> systems that have support for this.
>
>
>
> Is there a new trait in the TTI, or a call-back elsewhere that allows the
> target to choose whether it wants this optimisation to use an ADD or an OR
> (possibly in the cost-models)?  I would generally prefer to use ADD versus
> OR if the cost of execution is the same.
>
>
>
> Thanks,
>
>
>
>     MartinO
>
>
>
> --------------------------------------------------------------
> 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
>

Hi Sanjoy,

Yes these are C tests (from 'gcc.c-torture/execute'), and as I indicated
in my original message, the tests are not valid because the behaviour is
undefined.  However, it was while investigating these new failures in these
tests that I realised that this optimisation existed.

The optimisation itself is perfectly valid, but it does mean that integer
underflow will no longer be detected on systems which have hardware for this
purpose.

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.

Thanks,

	MartinO

-----Original Message-----
From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] 
Sent: Tuesday, October 3, 2017 5:59 AM
To: ORiordan, Martin <martin.oriordan at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Change in optimisation with UB in mind

It isn't just about execution on the target machine -- transforming the Add
to an Or makes it easier to infer that the highest bit of the result is always
set later in the optimization pipeline.  Are the failing tests unit tests for a
C compiler?  If so, I'd say the test cases are broken, unless they're
specifically test that e.g. the compiler does not crash when compiling code like
this.

-- Sanjoy

On Fri, Sep 29, 2017 at 4:34 AM, ORiordan, Martin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> With LLVM v5.0, I found failures in some of the ‘gcc.c-torture/execute’
> tests due to a change in the optimisation where undefined behaviour is 
> involved.  The tests that fail are the ‘20040409-[123].c’ tests.
>
>
>
> The underlying failure is due to the optimisation of the following:
>
>
>
>    int test2(int x) { return x + INT_MIN; }
>
>
>
> from using an ADD instruction to using an OR instruction.  The 
> optimisation is entirely valid and will produce the correct result for 
> all correct values of ‘x’, but it introduces a change for 
> architectures that have support for detecting integer overflow/underflow
(signalling or quiet).
>
>
>
> For many systems the execution cost of ADD versus OR is the same, so 
> there is no real reason to choose one versus the other, and UB is UB either
way.
> However, it does impact detection of out-of-range integer arithmetic 
> for systems that have support for this.
>
>
>
> Is there a new trait in the TTI, or a call-back elsewhere that allows 
> the target to choose whether it wants this optimisation to use an ADD 
> or an OR (possibly in the cost-models)?  I would generally prefer to 
> use ADD versus OR if the cost of execution is the same.
>
>
>
> Thanks,
>
>
>
>     MartinO
>
>
>
> --------------------------------------------------------------
> 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
>
--------------------------------------------------------------
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.