Displaying 5 results from an estimated 5 matches for "_f1".
Did you mean:
_f
2018 Apr 02
1
const struct auto vs. static
...the stack.
I had to remove const to make it work.
I realize such code is troublesome in the face of inlining.
We should probably mark some of our functions to not be inlined.
$ cat 3.c
void f2(const void*);
void f1()
{
const struct { int a; } b = { 0 };
f2(&b);
}
$ clang -c -S 3.c
$ cat 3.s
_f1: ## @f1
pushq %rbp
movq %rsp, %rbp
leaq _f1.b(%rip), %rax
movq %rax, %rdi
callq _f2
popq %rbp
retq
$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Co...
2011 Dec 14
2
[LLVMdev] Failure to optimize ? operator
...ere T() is the time to execute the given function.
So always T(f1) <= T(f2).
I would call this a missed optimization opportunity. I think it
warrants a bug report.
If I do the same experiment with gcc I get identical code for the two functions:
==============================================
_f1: pushl %ebp xorl %eax, %eax movl
%esp, %ebp movl 8(%ebp), %edx testl %edx, %edx
jle L5 popl %ebp ret .p2align 4,,7L5:
movl %edx, %ecx imull %edx, %ecx popl %ebp
leal 3(%ecx,%ecx,4), %eax ...
2018 Apr 05
2
double to unsigned char cast
...signed char)(int)i;
}
$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ clang -arch arm64 -O2 -S -c /s/1.c && more 1.s
_f1:
fcvtzs w0, d0
ret
_f2:
fcvtzs w8, d0
and w0, w8, #0xff
ret
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180405/652a038c/attachment.html>
2011 Dec 14
0
[LLVMdev] Failure to optimize ? operator
On Tue, Dec 13, 2011 at 5:59 AM, Brent Walker <brenthwalker at gmail.com> wrote:
> The following seemingly identical functions, get compiled to quite
> different machine code. The first is correctly optimized (the
> computation of var y is nicely moved into the else branch of the "if"
> statement), which the second one is not (the full computation of var y
> is
2011 Dec 13
4
[LLVMdev] Failure to optimize ? operator
The following seemingly identical functions, get compiled to quite
different machine code. The first is correctly optimized (the
computation of var y is nicely moved into the else branch of the "if"
statement), which the second one is not (the full computation of var y
is always done). The output was produced using the demo page on
llvm's web site (optimization level LTO).
Can