search for: unarguably

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

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

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

(Hi Mike!) On May 1, 2008, at 6:11 PM, Mike Stump wrote: > 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

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

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

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:

On May 1, 2008, at 3:39 PM, David Vandevoorde wrote: > > Not quite. Although there is a requirement there (and more precise > ones in Clause 3), there is no prohibition against doing additional, > observable stuff (e.g., log the calls) and hence allocations cannot > be elided. That's correct, there is no prohibition, but, if one does, there are no requirements placed

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

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