search for: unargu

...st of breed and with no compromises w.r.t. that goal. 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 while innovation in the linker space (e.g. a new “native” object file format generated directly from compiler structures) may or may not actually “work” or be “worth it”, we won’t know unless we try, and that won’t fulfill its promise if t...

...es w.r.t. that > goal. > > > 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 while innovation in the linker space (e.g. a new > “native” object file format generated directly from compiler structures) > may or may not actually “work” or be “worth it”, we won’t know unless we > try, and that won’t fulf...

.... >> >> >> 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 while innovation in the linker space (e.g. a new >> “native” object file format generated directly from compiler structures) >> may or may not actually “work” or be “worth it”, we won’t know unless we >> try, and...

...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...

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

...> 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 while innovation in the linker space (e.g. a new >>>> “native” object file format generated directly from compiler structures) >>>> may or may not actually “work” or be “worth it”, we won’t know unl...

...nd with no compromises w.r.t. that goal. > > > 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 while innovation in the linker space (e.g. a new “native” object file format generated directly from compiler structures) may or may not actually “work” or be “worth it”, we won’t know unless we try, and that won’t fulfill its promise if t...

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:

...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...

...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 while innovation in the linker space > (e.g. a new “native” object file format generated directly from > compiler structures) may or may not actually “work” or be “worth it”, > we won’t know unless we try, and that won’t fulf...

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