Displaying 11 results from an estimated 11 matches for "unarguable".
Did you mean:
unarguably
2015 May 04
0
[LLVMdev] LLD improvement plan
On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote:
> Proposal
> Re-architect the linker based on the section model where it’s appropriate.
> Stop simulating different linker semantics using the Unix model. Instead, directly implement the native behavior.
Preface: I have never personally contributed code to LLD, so don’t take anything I’m about to say too seriously.
2015 May 06
3
[LLVMdev] LLD improvement plan
I'm sorry if my suggestion gave an impression that I disregard the Mach-O
port of the LLD linker. I do care about Mach-O. I do not plan to break or
remove any functionality from the current Mach-O port of the LLD. I don't
propose to remove the atom model from the linker as long as it seems to be
a good fit for the port (and looks like it is).
As to the proposal to have two different
2015 May 07
2
[LLVMdev] LLD improvement plan
On Thu, May 7, 2015 at 12:58 PM, Jim Grosbach <grosbach at apple.com> wrote:
> Hi Rui,
>
> Thank you for clarifying. This is very helpful.
>
> It’s unfortunate that you’re not seeing benefits from the increased
> semantic knowledge the atom based model can provide. I know you’ve explored
> the issue thoroughly, though, so I understand why you’re wanting to move a
>
2008 May 01
3
[LLVMdev] optimization assumes malloc return is non-null
...t with a user-written operator new, there may be
other valid ways (besides operator new) to get at the storage
returned. The object lifetime rules don't always give such programs
undefined behavior.
(I personally consider this a defect in the standard, but I don't
think that's unarguable.)
>
>> There are a huge number of code pessimizations that happen because
>> the optimizer has to
>> assume that 'new' can return a pointer that already exists in the
>> program.
>
> This one is safe. It has to behaves as if it allocates storage. If
>...
2015 May 01
15
[LLVMdev] LLD improvement plan
Hi guys, After working for a long period of time on LLD, I think I found a
few things that we should improve in the LLD design for both development
ease and runtime performance. I would like to get feedback on this
proposal. Thanks! *Problems with the current LLD architecture *The current
LLD architecture has, in my opinion, two issues.
*The atom model is not the best model for some architectures
2015 May 24
2
[LLVMdev] LLD improvement plan
I'm sorry for not updating the thread -- I thought I did that before.
I started experimenting the idea by implementing a minimal linker using the
section-based design with some additional simplification/optimizations.
It's already able to link small programs like the LLD itself, and the
performance looks indeed better (probably the LLD is too small as a
benchmark, but the new one is more
2015 May 07
4
[LLVMdev] LLD improvement plan
Hi,
There are a lot of advantages to keep on improving the atom model and
working on that model.
The atom model allowed lld to have a single intermediate representation
for all the formats ELF/COFF/Mach-O. The native model allowed the
intermediate representation to be serialized to disk too. If the
intermediate representations data structures are made available to
scripting languages most
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 9:26 PM, Chris Lattner wrote:
> Personally to me, I have a bigger axe to grind with C++ operator new.
> AFAIK, the standard doesn't give leeway to do a number of interesting
> optimizations for new/delete because the user is explicitly allowed to
> override them and the std doesn't require them to behave "as
> expected".
Yes it does:
2008 May 05
0
[LLVMdev] optimization assumes malloc return is non-null
...to unspecified behavior
(for reads) or undefined behavior (for writes) for allocations by the
system routines. Though, I do agree, the standard could be made more
clear exactly what we meant.
> (I personally consider this a defect in the standard, but I don't
> think that's unarguable.)
> Which part of the standard would I be missing that implies so?
A C++ implementation pro-
vides access to, and management of, dynamic storage via the
global
allocation functions operator new and operator new[] and the
global
deallocation functions operator delete and...
2015 May 04
4
[LLVMdev] LLD improvement plan
On Mon, May 04, 2015 at 12:52:55PM -0700, Chris Lattner wrote:
> I think the problem here is that these lead to natural and inescapable
> tensions, and Alex summarized how Camp B has been steering LLD away
> from what Camp A people want. This isn’t bad in and of itself, because
> what Camp B wants is clearly and unarguably good for LLVM. However,
> it is also not sufficient, and
2008 May 01
3
[LLVMdev] optimization assumes malloc return is non-null
On Apr 30, 2008, at 8:51 PM, David Vandevoorde wrote:
>> This isn't safe in general unless you can (tightly) bound "n". You
>> don't want to overflow the stack.
>
> Ah yes, of course. Does LLVM do this for known & small constant n?
We don't do this currently, primarily because I haven't seen a case
where it is a win yet: it would be very easy to