Martin J. O'Riordan via llvm-dev
2016-Sep-20 11:12 UTC
[llvm-dev] LLVM v3.9.0 and math built-ins
Hi Mehdi,
The ISO C specification does permit the math functions to modify ‘errno’, but I
thought that the ‘-fno-math-errno’ option was to tell the optimiser to assume
that ‘errno’ is not modified by the math functions. Explicitly providing
‘-fno-math-errno’ is not restoring the elision optimisation that was performed
by LLVM v3.8, and this is really only a driver option, with ‘-fmath-errno’
passed onto CC1 if ‘MathErrno’ is true, and omitted if false.
I certainly agree that if ‘MathErrno’ is true, then the compiler should not
elide the call as it has to assume that there are memory write side-effects. It
already models the math functions as built-ins and determine the expected answer
when the arguments are constants, and elides the tests in the simple example
below - all this is good, and when I use ‘-fno-builtin’ it stops correctly
disabled this optimisation.
I modified my sources to force ‘readnone’ and even tried
‘setDoesNotAccessMemory()’ on the math functions, but this still results in one
call occurring and the code generated is effectively:
(void)exp(1.0);
return 0;
This is better, but still not as optimal as it was in v3.8. With this change,
compiling with ‘-fmath-errno’ reverts to inserting two calls.
While calling these functions with constants is not terribly common in C code
(mostly contrived test cases), it is a lot more common in real C++ code via
template expansions and inlining. With ‘-O3 -S -emit-llvm -fno-math-errno’ plus
my change to call ‘setDoesNotAccessMemory()’, the IR generated is as follows:
; ModuleID = 'src/mathElisions.c'
source_filename = "src/mathElisions.c"
target datalayout =
"e-m:e-p:32:32-f64:64-i64:64-v128:64-v64:64-v32:32-v16:16-n8:16:32-S64"
target triple = "shave"
; Function Attrs: nounwind readnone
define i32 @useMathName() local_unnamed_addr #0 {
%1 = tail call float @exp(float 1.000000e+00)
ret i32 0
}
; Function Attrs: readnone
declare float @exp(float) local_unnamed_addr #1
; Function Attrs: nounwind
define i32 @useOtherName() local_unnamed_addr #2 {
%1 = tail call float @foo(float 1.000000e+00) #4
%2 = fcmp olt float %1, 0x4005AE1480000000
br i1 %2, label %7, label %3
; <label>:3: ; preds = %0
%4 = tail call float @foo(float 1.000000e+00) #4
%5 = fcmp ogt float %4, 0x4005C28F60000000
br i1 %5, label %7, label %6
; <label>:6: ; preds = %3
br label %7
; <label>:7: ; preds = %0, %3, %6
%8 = phi i32 [ 0, %6 ], [ -1, %3 ], [ -1, %0 ]
ret i32 %8
}
declare float @foo(float) local_unnamed_addr #3
attributes #0 = { nounwind readnone
"disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-jump-tables"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { readnone "disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #2 = { nounwind "disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-jump-tables"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #3 = { "disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #4 = { nounwind }
Our implementation has C ‘float’ and ‘double’ as 32-bit IEEE Single-Precision
and ‘long double’ as 64-bit IEEE Double-Precision.
Thanks,
MartinO
From: mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>
[mailto:mehdi.amini at apple.com]
Sent: 16 September 2016 21:16
On Sep 16, 2016, at 1:30 AM, Martin J. O'Riordan via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:
A little while ago I asked a question on CFE-Dev about a change in the behaviour
of programs using the ISO C math functions, although that question should have
been put to LLVM-Dev. But I got excellent clarification of the problem anyway.
However, since then I have been trying to adapt our out-of-tree implementation
to get the previous behaviour. The problem is that something like:
#include <math.h>
extern double foo(double);
int useMathName() {
if ((exp(1.0) < 2.71) || (exp(1.0) > 2.72))
return -1;
return 0;
}
int useOtherName() {
if ((foo(1.0) < 2.71) || (foo(1.0) > 2.72))
return -1;
return 0;
}
With v3.8.0 the compiler elided both the calls to ‘exp’ and the tests, so the
function ‘useMathName’ reduced to simply:
return 0;
But this was not correct as it ignored the possibility that the math functions
could have the side-effect of changing ‘errno’, and this was fixed in v3.9.0,
and the calls are no longer elided, though using the “as-if” rule, the tests are
still eliminated and ‘useMathName’ becomes:
(void)exp(1.0);
(void)exp(1.0);
o me: isn’t the spec saying that errno shall be set on underflow and overflow.
The constant folding should be able to detect this and fold if it does not
happen?
Also, because we don’t really model errno, we don’t constant fold these call
anymore :(
return 0;
So I changed our implementation so that ‘-fno-math-errno’ is the default for the
tool-chain, and the ‘-fmath-errno’ option is not passed on to the CC1 phase. I
expected that this would allow the compiler to elide the calls, but it is not
doing so. I don’t want to use ‘-ffast-math’ as this has lots of FP issues, and
I don’t want to make it the default.
Any idea why the math functions are not elided? I am using ‘-O3’ and implying
‘-fno-math-errno’. I have verified that our Toolchain implements
‘IsMathErrnoDefault’ and returns ‘false’, and that the option ‘-fmath-errno’ is
not being passed to the CC1 stage. Since our math function implementation does
not in fact change ‘errno’, it is very desirable that this elision occurs in an
FP safe way.
You can check that clang when emitting the IR is adding the attribute
"readnone” on the declaration of exp(). If it does not then it assumes
errno.
As a starting point, have you tried to pass -fno-math-errno?
—
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160920/5a6eb973/attachment.html>
Hi Martin, I believe Mehdi was referring to C11 subclause 7.12.1 paragraph 7: If no such error occurs, errno shall be left unmodified regardless of the setting of math_errhandling. Thus we are left with a question as to why a call with the constant is needs to be preserved when errno is specified not to change by C11. -- HT On Tue, Sep 20, 2016 at 7:12 AM, Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Mehdi, > > > > The ISO C specification does permit the math functions to modify ‘errno’, > but I thought that the ‘-fno-math-errno’ option was to tell the > optimiser to assume that ‘errno’ is not modified by the math functions. > Explicitly providing ‘-fno-math-errno’ is not restoring the elision > optimisation that was performed by LLVM v3.8, and this is really only a > driver option, with ‘-fmath-errno’ passed onto CC1 if ‘MathErrno’ is > true, and omitted if false. > > > > I certainly agree that if ‘MathErrno’ is true, then the compiler should > not elide the call as it has to assume that there are memory write > side-effects. It already models the math functions as built-ins and > determine the expected answer when the arguments are constants, and elides > the tests in the simple example below - all this is good, and when I use ‘ > -fno-builtin’ it stops correctly disabled this optimisation. > > > > I modified my sources to force ‘readnone’ and even tried ‘ > setDoesNotAccessMemory()’ on the math functions, but this still results > in one call occurring and the code generated is effectively: > > > > (void)exp(1.0); > > return 0; > > > > This is better, but still not as optimal as it was in v3.8. With this > change, compiling with ‘-fmath-errno’ reverts to inserting two calls. > > > > While calling these functions with constants is not terribly common in C > code (mostly contrived test cases), it is a lot more common in real C++ > code via template expansions and inlining. With ‘-O3 -S -emit-llvm > -fno-math-errno’ plus my change to call ‘setDoesNotAccessMemory()’, the > IR generated is as follows: > > > > ; ModuleID = 'src/mathElisions.c' > > source_filename = "src/mathElisions.c" > > target datalayout = "e-m:e-p:32:32-f64:64-i64:64- > v128:64-v64:64-v32:32-v16:16-n8:16:32-S64" > > target triple = "shave" > > > > ; Function Attrs: nounwind readnone > > define i32 @useMathName() local_unnamed_addr #0 { > > %1 = tail call float @exp(float 1.000000e+00) > > ret i32 0 > > } > > > > ; Function Attrs: readnone > > declare float @exp(float) local_unnamed_addr #1 > > > > ; Function Attrs: nounwind > > define i32 @useOtherName() local_unnamed_addr #2 { > > %1 = tail call float @foo(float 1.000000e+00) #4 > > %2 = fcmp olt float %1, 0x4005AE1480000000 > > br i1 %2, label %7, label %3 > > > > ; <label>:3: ; preds = %0 > > %4 = tail call float @foo(float 1.000000e+00) #4 > > %5 = fcmp ogt float %4, 0x4005C28F60000000 > > br i1 %5, label %7, label %6 > > > > ; <label>:6: ; preds = %3 > > br label %7 > > > > ; <label>:7: ; preds = %0, %3, %6 > > %8 = phi i32 [ 0, %6 ], [ -1, %3 ], [ -1, %0 ] > > ret i32 %8 > > } > > > > declare float @foo(float) local_unnamed_addr #3 > > > > attributes #0 = { nounwind readnone "disable-tail-calls"="false" > "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" > "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" > "no-jump-tables"="false" "no-nans-fp-math"="false" > "no-signed-zeros-fp-math"="false" "stack-protector-buffer-size"="8" > "target-cpu"="myriad2.2" "unsafe-fp-math"="false" "use-soft-float"="false" } > > attributes #1 = { readnone "disable-tail-calls"="false" > "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" > "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" > "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" > "stack-protector-buffer-size"="8" "target-cpu"="myriad2.2" > "unsafe-fp-math"="false" "use-soft-float"="false" } > > attributes #2 = { nounwind "disable-tail-calls"="false" > "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" > "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" > "no-jump-tables"="false" "no-nans-fp-math"="false" > "no-signed-zeros-fp-math"="false" "stack-protector-buffer-size"="8" > "target-cpu"="myriad2.2" "unsafe-fp-math"="false" "use-soft-float"="false" } > > attributes #3 = { "disable-tail-calls"="false" > "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" > "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" > "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" > "stack-protector-buffer-size"="8" "target-cpu"="myriad2.2" > "unsafe-fp-math"="false" "use-soft-float"="false" } > > attributes #4 = { nounwind } > > > > Our implementation has C ‘float’ and ‘double’ as 32-bit IEEE > Single-Precision and ‘long double’ as 64-bit IEEE Double-Precision. > > > > Thanks, > > > > MartinO > > > > *From:* mehdi.amini at apple.com [mailto:mehdi.amini at apple.com > <mehdi.amini at apple.com>] > *Sent:* 16 September 2016 21:16 > > > > On Sep 16, 2016, at 1:30 AM, Martin J. O'Riordan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > A little while ago I asked a question on CFE-Dev about a change in the > behaviour of programs using the ISO C math functions, although that > question should have been put to LLVM-Dev. But I got excellent > clarification of the problem anyway. However, since then I have been > trying to adapt our out-of-tree implementation to get the previous > behaviour. The problem is that something like: > > > > #include <math.h> > > > > extern double foo(double); > > > > int useMathName() { > > if ((exp(1.0) < 2.71) || (exp(1.0) > 2.72)) > > return -1; > > return 0; > > } > > > > int useOtherName() { > > if ((foo(1.0) < 2.71) || (foo(1.0) > 2.72)) > > return -1; > > return 0; > > } > > > > With v3.8.0 the compiler elided both the calls to ‘exp’ and the tests, so > the function ‘useMathName’ reduced to simply: > > > > return 0; > > > > But this was not correct as it ignored the possibility that the math > functions could have the side-effect of changing ‘errno’, and this was > fixed in v3.9.0, and the calls are no longer elided, though using the > “as-if” rule, the tests are still eliminated and ‘useMathName’ becomes: > > > > (void)exp(1.0); > > (void)exp(1.0); > > > > o me: isn’t the spec saying that errno shall be set on underflow and > overflow. The constant folding should be able to detect this and fold if it > does not happen? > > > > Also, because we don’t really model errno, we don’t constant fold these > call anymore :( > > > > return 0; > > > > So I changed our implementation so that ‘-fno-math-errno’ is the default > for the tool-chain, and the ‘-fmath-errno’ option is not passed on to the > CC1 phase. I expected that this would allow the compiler to elide the > calls, but it is not doing so. I don’t want to use ‘-ffast-math’ as this > has lots of FP issues, and I don’t want to make it the default. > > > > Any idea why the math functions are not elided? I am using ‘-O3’ and > implying ‘-fno-math-errno’. I have verified that our Toolchain > implements ‘IsMathErrnoDefault’ and returns ‘false’, and that the option ‘ > -fmath-errno’ is not being passed to the CC1 stage. Since our math > function implementation does not in fact change ‘errno’, it is very > desirable that this elision occurs in an FP safe way. > > > > You can check that clang when emitting the IR is adding the attribute > "readnone” on the declaration of exp(). If it does not then it assumes > errno. > > > > As a starting point, have you tried to pass -fno-math-errno? > > > > — > > Mehdi > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160920/7ebf011e/attachment-0001.html>
Martin J. O'Riordan via llvm-dev
2016-Sep-20 14:07 UTC
[llvm-dev] LLVM v3.9.0 and math built-ins
I was compiling without ‘-std’ (default ANSI C89 I presume), but this still
happens when I provide ‘-std=c11’, so it does seem like something has broken.
Guess it’s back to sleuthing through the change logs :)
Thanks for your help,
MartinO
From: Hubert Tong [mailto:hubert.reinterpretcast at gmail.com]
Sent: 20 September 2016 14:54
To: Martin J. O'Riordan <martin.oriordan at movidius.com>
Cc: mehdi.amini at apple.com; LLVM Developers <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] LLVM v3.9.0 and math built-ins
Hi Martin,
I believe Mehdi was referring to C11 subclause 7.12.1 paragraph 7:
If no such error occurs, errno shall be left unmodified regardless of the
setting of math_errhandling.
Thus we are left with a question as to why a call with the constant is needs to
be preserved when errno is specified not to change by C11.
-- HT
On Tue, Sep 20, 2016 at 7:12 AM, Martin J. O'Riordan via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >
wrote:
Hi Mehdi,
The ISO C specification does permit the math functions to modify ‘errno’, but I
thought that the ‘-fno-math-errno’ option was to tell the optimiser to assume
that ‘errno’ is not modified by the math functions. Explicitly providing
‘-fno-math-errno’ is not restoring the elision optimisation that was performed
by LLVM v3.8, and this is really only a driver option, with ‘-fmath-errno’
passed onto CC1 if ‘MathErrno’ is true, and omitted if false.
I certainly agree that if ‘MathErrno’ is true, then the compiler should not
elide the call as it has to assume that there are memory write side-effects. It
already models the math functions as built-ins and determine the expected answer
when the arguments are constants, and elides the tests in the simple example
below - all this is good, and when I use ‘-fno-builtin’ it stops correctly
disabled this optimisation.
I modified my sources to force ‘readnone’ and even tried
‘setDoesNotAccessMemory()’ on the math functions, but this still results in one
call occurring and the code generated is effectively:
(void)exp(1.0);
return 0;
This is better, but still not as optimal as it was in v3.8. With this change,
compiling with ‘-fmath-errno’ reverts to inserting two calls.
While calling these functions with constants is not terribly common in C code
(mostly contrived test cases), it is a lot more common in real C++ code via
template expansions and inlining. With ‘-O3 -S -emit-llvm -fno-math-errno’ plus
my change to call ‘setDoesNotAccessMemory()’, the IR generated is as follows:
; ModuleID = 'src/mathElisions.c'
source_filename = "src/mathElisions.c"
target datalayout =
"e-m:e-p:32:32-f64:64-i64:64-v128:64-v64:64-v32:32-v16:16-n8:16:32-S64"
target triple = "shave"
; Function Attrs: nounwind readnone
define i32 @useMathName() local_unnamed_addr #0 {
%1 = tail call float @exp(float 1.000000e+00)
ret i32 0
}
; Function Attrs: readnone
declare float @exp(float) local_unnamed_addr #1
; Function Attrs: nounwind
define i32 @useOtherName() local_unnamed_addr #2 {
%1 = tail call float @foo(float 1.000000e+00) #4
%2 = fcmp olt float %1, 0x4005AE1480000000
br i1 %2, label %7, label %3
; <label>:3: ; preds = %0
%4 = tail call float @foo(float 1.000000e+00) #4
%5 = fcmp ogt float %4, 0x4005C28F60000000
br i1 %5, label %7, label %6
; <label>:6: ; preds = %3
br label %7
; <label>:7: ; preds = %0, %3, %6
%8 = phi i32 [ 0, %6 ], [ -1, %3 ], [ -1, %0 ]
ret i32 %8
}
declare float @foo(float) local_unnamed_addr #3
attributes #0 = { nounwind readnone
"disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-jump-tables"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { readnone "disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #2 = { nounwind "disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-jump-tables"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #3 = { "disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="myriad2.2"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #4 = { nounwind }
Our implementation has C ‘float’ and ‘double’ as 32-bit IEEE Single-Precision
and ‘long double’ as 64-bit IEEE Double-Precision.
Thanks,
MartinO
From: mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>
[mailto:mehdi.amini at apple.com]
Sent: 16 September 2016 21:16
On Sep 16, 2016, at 1:30 AM, Martin J. O'Riordan via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:
A little while ago I asked a question on CFE-Dev about a change in the behaviour
of programs using the ISO C math functions, although that question should have
been put to LLVM-Dev. But I got excellent clarification of the problem anyway.
However, since then I have been trying to adapt our out-of-tree implementation
to get the previous behaviour. The problem is that something like:
#include <math.h>
extern double foo(double);
int useMathName() {
if ((exp(1.0) < 2.71) || (exp(1.0) > 2.72))
return -1;
return 0;
}
int useOtherName() {
if ((foo(1.0) < 2.71) || (foo(1.0) > 2.72))
return -1;
return 0;
}
With v3.8.0 the compiler elided both the calls to ‘exp’ and the tests, so the
function ‘useMathName’ reduced to simply:
return 0;
But this was not correct as it ignored the possibility that the math functions
could have the side-effect of changing ‘errno’, and this was fixed in v3.9.0,
and the calls are no longer elided, though using the “as-if” rule, the tests are
still eliminated and ‘useMathName’ becomes:
(void)exp(1.0);
(void)exp(1.0);
o me: isn’t the spec saying that errno shall be set on underflow and overflow.
The constant folding should be able to detect this and fold if it does not
happen?
Also, because we don’t really model errno, we don’t constant fold these call
anymore :(
return 0;
So I changed our implementation so that ‘-fno-math-errno’ is the default for the
tool-chain, and the ‘-fmath-errno’ option is not passed on to the CC1 phase. I
expected that this would allow the compiler to elide the calls, but it is not
doing so. I don’t want to use ‘-ffast-math’ as this has lots of FP issues, and
I don’t want to make it the default.
Any idea why the math functions are not elided? I am using ‘-O3’ and implying
‘-fno-math-errno’. I have verified that our Toolchain implements
‘IsMathErrnoDefault’ and returns ‘false’, and that the option ‘-fmath-errno’ is
not being passed to the CC1 stage. Since our math function implementation does
not in fact change ‘errno’, it is very desirable that this elision occurs in an
FP safe way.
You can check that clang when emitting the IR is adding the attribute
"readnone” on the declaration of exp(). If it does not then it assumes
errno.
As a starting point, have you tried to pass -fno-math-errno?
—
Mehdi
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160920/a113ae99/attachment.html>
Friedman, Eli via llvm-dev
2016-Sep-20 17:13 UTC
[llvm-dev] LLVM v3.9.0 and math built-ins
On 9/20/2016 4:12 AM, Martin J. O'Riordan via llvm-dev wrote:> > I modified my sources to force ‘readnone’ and even tried > ‘setDoesNotAccessMemory()’ on the math functions, but this still > results in one call occurring and the code generated is effectively: > > (void)exp(1.0); > > return 0; > > %1 = tail call float @exp(float 1.000000e+00) > > ; Function Attrs: readnone > > declare float @exp(float) local_unnamed_addr #1 >You have to set readonly on the call, not the function ("tail call float @exp(float 1.000000e+00) readonly") ; the attributes on a function declaration are generally ignored by LLVM. For the difference between 3.8 and 3.9, see https://llvm.org/bugs/show_bug.cgi?id=30464 . -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160920/b61c99df/attachment-0001.html>
Martin J. O'Riordan via llvm-dev
2016-Sep-21 09:44 UTC
[llvm-dev] LLVM v3.9.0 and math built-ins
Thanks Eli,
My edits are just experiments to see if I could fix it, but I am not familiar
with this area of the code and my approach is inevitably naïve.
All the best,
MartinO
From: Friedman, Eli [mailto:efriedma at codeaurora.org]
Sent: 20 September 2016 18:14
To: Martin J. O'Riordan <martin.oriordan at movidius.com>; mehdi.amini
at apple.com
Cc: 'LLVM Developers' <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] LLVM v3.9.0 and math built-ins
On 9/20/2016 4:12 AM, Martin J. O'Riordan via llvm-dev wrote:
I modified my sources to force ‘readnone’ and even tried
‘setDoesNotAccessMemory()’ on the math functions, but this still results in one
call occurring and the code generated is effectively:
(void)exp(1.0);
return 0;
%1 = tail call float @exp(float 1.000000e+00)
; Function Attrs: readnone
declare float @exp(float) local_unnamed_addr #1
You have to set readonly on the call, not the function ("tail call float
@exp(float 1.000000e+00) readonly") ; the attributes on a function
declaration are generally ignored by LLVM.
For the difference between 3.8 and 3.9, see
https://llvm.org/bugs/show_bug.cgi?id=30464 .
-Eli
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160921/67170627/attachment.html>