Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] calling conventions and inlining"
2005 May 07
0
[LLVMdev] calling conventions and inlining
On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
> Chris Lattner wrote:
>> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
>>
>>> As I've just seen that there are some things going on w.r.t the long
>>> needed implementation of calling conventions, may I also ask if it's
>>> possible to address inlining at the same moment (i.e. attributes
2005 May 07
0
[LLVMdev] calling conventions and inlining
On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
> As I've just seen that there are some things going on w.r.t the long needed
> implementation of calling conventions, may I also ask if it's possible to
> address inlining at the same moment (i.e. attributes always_inline and
> noinline, but maybe LLVM wants a finer grained level here) ?
They really are different issues.
2005 May 08
0
[LLVMdev] calling conventions and inlining
On Sun, 8 May 2005, Markus F.X.J. Oberhumer wrote:
> Chris Lattner wrote:
>> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
>>> but looking at the disassembly suggests that this might mainly be an issue
>>> of x86 codegen, which is rather young as compared to other compilers.
>> If you're testing on X86, I would be strongly suspious of the X86 backend,
2005 May 07
0
[LLVMdev] calling conventions and inlining
On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
> Actually I feel that the current state of the art of inlining is where
> register allocation has been about 10 years ago. It's pretty fine for most
> things, but back then I remember writing code like "register const char *p
> __asm__("%esi");" where just adding the explicit __asm__ boosted performance
2005 May 08
0
[LLVMdev] calling conventions and inlining
On Sun, 2005-05-08 at 02:52 +0200, Markus F.X.J. Oberhumer wrote:
> Put simply, the inliner is too greedy and nice little leaf functions
> suddenly run out of CPU registers. Even gcc 3.4 with -funit-at-a-time
> started inlining too much, but at least I can tell gcc where to stop.
> This whole noinline issue may be somewhat X86 specific, though.
This is where a register allocator
2005 May 07
0
[LLVMdev] calling conventions and inlining
There is one case where inlining/not-inlining affects correctness. A
function which uses alloca() will behave differently in the two cases.
You can argue one shouldn't write code like this, but it is legal.
Chris Lattner wrote:
> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
>
>> I see that you are objecting explicit inline control.
>>
>> The main problem is
2005 May 07
2
[LLVMdev] calling conventions and inlining
On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
> I see that you are objecting explicit inline control.
>
> The main problem is that inlining is absolutely crucial for some
> "modern" programming styles. E.g. we use a huge collection of small C++
> template classes and template metaclasses, most of which have very
> trivial and limited functionality (think of it
2018 Jul 20
0
[PATCH 4.4 04/31] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nick Desaulniers <ndesaulniers at google.com>
commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.
Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+
2018 Jul 20
0
[PATCH 4.9 05/66] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nick Desaulniers <ndesaulniers at google.com>
commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.
Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+
2018 Jul 20
0
[PATCH 4.14 01/92] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nick Desaulniers <ndesaulniers at google.com>
commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.
Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC
2018 Jul 20
0
[PATCH 4.17 001/101] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
4.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nick Desaulniers <ndesaulniers at google.com>
commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.
Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC
2005 Feb 11
1
[LLVMdev] Function attributes and bytecode
On Thursday 10 February 2005 21:47, Markus F.X.J. Oberhumer wrote:
> In order to get more familiar with the llvm sources I've recently
> decided to try to add support for the always_inline and noline function
> attributes.
I believe it is better to let the compiler decide when or not to inline a
function. Most of the times a developer goes overboard with inlining and ends
up with a
2018 Jul 18
0
Patch "compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations" has been added to the 4.4-stable tree
This is a note to let you know that I've just added the patch titled
compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
compiler-gcc.h-add-__attribute__-gnu_inline-to-all-inline-declarations.patch
and
2018 Jul 18
0
Patch "compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
compiler-gcc.h-add-__attribute__-gnu_inline-to-all-inline-declarations.patch
2018 Jul 18
0
Patch "compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations" has been added to the 4.17-stable tree
This is a note to let you know that I've just added the patch titled
compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
to the 4.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
compiler-gcc.h-add-__attribute__-gnu_inline-to-all-inline-declarations.patch
2018 Jul 18
0
Patch "compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations" has been added to the 4.9-stable tree
This is a note to let you know that I've just added the patch titled
compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
compiler-gcc.h-add-__attribute__-gnu_inline-to-all-inline-declarations.patch
and
2006 Mar 14
0
[LLVMdev] Selectively Disable Inlining for Functions
On Tue, 7 Mar 2006, Markus F.X.J. Oberhumer wrote:
> Still, my approach makes the inline hint a first-class property of an LLVM
> function just like the calling convention, including preserving full source
> code information.
Preserving full source code information isn't a goal of LLVM, at least if
you don't count debug information. :)
> Most of the patch is actually
2019 Nov 04
3
Fix clang's 'flatten' function attribute: add depth to always_inline?
Hi everyone,
clang currently implements the 'flatten' function attribute by marking
all calls to not 'noinline' functions with 'always_inline'. In effect,
only the first level of calls is inlined, not all calls recursively
(like gcc does).
We briefly discussed possible solutions on IRC:
We could add an equivalent LLVM attribute for functions (e.g.
'flatten'). The
2006 Mar 07
1
[LLVMdev] Selectively Disable Inlining for Functions
On Tue, 7 Mar 2006, Markus F.X.J. Oberhumer wrote:
>> I'm currently working with an experimental analysis pass that checks for
>> calls to memory allocation functions; inlining and dead code elimination
>> might make the pass more stable, but we don't want to inline the calls to
>> the memory allocation functions until after our analysis pass is finished.
>
2008 Aug 25
0
[LLVMdev] Proposal : Function Notes
Hi Devang,
I have a few questions below.
On Aug 22, 2008, at 4:40 PM, Devang Patel wrote:
> Here is a proposal that I mentioned sometime ago. Any
> thoughts,comments or
> suggestions on this proposal would be appreciated.
> -
> Devang
>
> //
> =
> =
> =
> ----------------------------------------------------------------------=
> ==//
> //