Displaying 3 results from an estimated 3 matches for "luo2".
Did you mean:
luo
2018 Dec 04
2
[Unsafe-fp-math] Merge attribute for inlining
...trying to understand the underlying concern. That means the inlining of a callee without unsafe-fp-math attribute set will block the unsafe optimization in its caller, right?
Thanks,
Yan
From: Finkel, Hal J. [mailto:hfinkel at anl.gov]
Sent: Tuesday, December 4, 2018 11:34 AM
To: Yan Luo <yan.luo2 at synopsys.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining
On 12/4/18 12:34 PM, Yan Luo via llvm-dev wrote:
Hello dev,
I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with log...
2019 Mar 01
2
Condition removed? Difference between LLVM and GCC on a small testcase
Hello Dev,
I have a very simple testcase, which shows strange difference between LLVM and GCC. Does anyone know which optimization pass removes the condition? Thanks!
C code:
extern void bar(int, int);
void foo(int a) {
int b, d;
if (a > 114) {
b = a * 58;
} else {
d = a * 51;
}
bar(b, d);
}
clang.7.0.1 -O2, LLVM generated assembly:
0: 6b c7 3a
2018 Dec 04
2
[Unsafe-fp-math] Merge attribute for inlining
Hello dev,
I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn't we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do