similar to: [LLVMdev] [PROPOSAL] ELF safe/unsafe sections

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] [PROPOSAL] ELF safe/unsafe sections"

2013 Jul 25
3
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 7/25/2013 3:56 PM, Rui Ueyama wrote: > I think I share the goal with you to make the foundation for better > dead-strip, so thank you for suggesting. I'm not sure if marking a section > as a whole as "safe" or "unsafe" is the best approach, though. Some > comments. > > - If the compiler generated code is always "safe", and if we can
2013 Jul 25
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. On Thu, Jul 25, 2013 at 2:01 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 7/25/2013 3:56 PM, Rui Ueyama wrote: > >> I
2013 Jul 25
2
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
Not all users compile their code with -ffunction-sections and -fdata-sections. This is to handle usecases when libraries use a mix of object files too. On 7/25/2013 4:10 PM, Rui Ueyama wrote: > Is there any reason -ffunction-sections and -fdata-sections wouldn't work? > If it'll work, it may be be better to say "if you want to get a better > linker output use
2013 Jul 25
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
I think I share the goal with you to make the foundation for better dead-strip, so thank you for suggesting. I'm not sure if marking a section as a whole as "safe" or "unsafe" is the best approach, though. Some comments. - If the compiler generated code is always "safe", and if we can distinguish it from hand-written assembly code by checking if there's a
2013 Jul 25
2
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
Then how about enable these flags for -O2? I want to hear from other people cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF section if there's other mean already available to achieve the same thing. On Thu, Jul 25, 2013 at 2:12 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Not all users compile their code with -ffunction-sections and >
2013 Jul 31
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 7/30/2013 7:41 PM, Chandler Carruth wrote: > I've not been following this thread at all. However, skimming the original > post, I fail to find a nice summary of what problem is trying to be solved. The proposal is trying to garbage collect symbols that are not referenced during the link step. In addition this proposal can be extended to keep frequently called
2013 Jul 26
1
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 7/26/2013 7:39 AM, Rafael EspĂ­ndola wrote: > On 25 July 2013 17:24, Rui Ueyama <ruiu at google.com> wrote: >> Then how about enable these flags for -O2? I want to hear from other people >> cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF >> section if there's other mean already available to achieve the same thing. > I would
2013 Jul 31
4
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
I've not been following this thread at all. However, skimming the original post, I fail to find a nice summary of what problem is trying to be solved. By reading the rest of the thread I divine that the goal is faster links and better dead code stripping? Making that clearer would help. Naming your sections something other than "safe" (which has *very* different connotations) would
2013 Jul 31
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 7/30/2013 5:43 PM, Nick Kledzik wrote: > On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: > >> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get
2013 Jul 30
3
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: > On 7/29/2013 11:24 AM, Nick Kledzik wrote: >> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining
2013 Jul 31
1
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On Tue, Jul 30, 2013 at 8:17 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 7/30/2013 7:41 PM, Chandler Carruth wrote: > >> I've not been following this thread at all. However, skimming the original >> post, I fail to find a nice summary of what problem is trying to be >> solved. >> > The proposal is trying to garbage collect
2013 Jul 31
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 25/07/13 18:54, Shankar Easwaran wrote: > Hi, > > Currently lld ties up all atoms in a section for ELF together. This > proposal just breaks it by handling it differently. > > *This requires **NO ELF ABI changes. > > *_*Definitions :-*_ > > A section is not considered safe if there is some code that appears to > be present between function boundaries
2013 Jul 29
4
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: > Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. >From my understanding, -ffunction-sections is a good semantic match. But it introduces a lot of bloat in
2013 Jul 31
1
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 7/30/2013 7:50 PM, Eric Christopher wrote: > On Tue, Jul 30, 2013 at 5:36 PM, Nick Kledzik <kledzik at apple.com> wrote: >> On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote: >>> On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> wrote: >>>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>>>> Is there any
2013 Jul 29
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 7/29/2013 11:24 AM, Nick Kledzik wrote: > On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. > >From my understanding, -ffunction-sections
2013 Jul 31
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On Tue, Jul 30, 2013 at 5:36 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote: >> On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> wrote: >>> >>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>>> Is there any reason -ffunction-sections and -fdata-sections wouldn't
2013 Jul 31
2
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
Thanks for your very detailed analysis. From other email conversations, it looks like -ffunction-sections and -fdata-sections are doing what is being iterated in the original proposal. On 7/31/2013 5:38 AM, Richard Osborne wrote: > I'd like to see a more precise definition of "safe". For example just > from the above description it is not clear that "safe"
2013 Jul 31
1
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
Can you guys invent a more specific word than "safe" to describe this concept? The best thing I can come up with is something like "atomizable section". This is basically describing code and data that the linker should feel free to strip and reorder, right? I'm not tracking this closely enough to be totally sure if that's a reasonable word for this. On Tue, Jul 30,
2013 Jul 31
2
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote: > On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use
2013 Jul 31
0
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
On 31 Jul 2013, at 16:32, Shankar Easwaran <shankare at codeaurora.org> wrote: > Thanks for your very detailed analysis. From other email conversations, it looks like -ffunction-sections and -fdata-sections are doing what is being iterated in the original proposal. Thanks for your answers :) > > On 7/31/2013 5:38 AM, Richard Osborne wrote: >> I'd like to see a