search for: pouly

Oh yes you're right, I missed that :) But the point still hold. Amaury Pouly 2010/8/8 Eugene Toder <eltoder at gmail.com> > > Not only this code does not compile with NDEBUG set > > I may be missing something, but why does it not compile with -DNDEBUG? > assert() macro expands to noop when NDEBUG is set. > > Eugene > > On Sun, Aug 8, 2010...

...ve(NumNodes * 2); So for some reason *2 is not enough in your case. I guess the right thing here is to either have a way to reliably estimate the number of SUnits (if it's at all possible) or use a container that doesn't reallocate on insert. Eugene On Sun, Aug 8, 2010 at 3:11 PM, Amaury Pouly <amaury.pouly at gmail.com> wrote: > Oh yes you're right, I missed that :) But the point still hold. > > Amaury Pouly > > > 2010/8/8 Eugene Toder <eltoder at gmail.com> >> >> > Not only this code does not compile with NDEBUG set >> >> I m...

> Not only this code does not compile with NDEBUG set I may be missing something, but why does it not compile with -DNDEBUG? assert() macro expands to noop when NDEBUG is set. Eugene On Sun, Aug 8, 2010 at 2:19 PM, Amaury Pouly <amaury.pouly at gmail.com> wrote: > Hello, > I was trying to interface a custom backend instruction scheduler with llvm > code when I realize something terrible. The scheduling code builds a graph > made up of SUnit * nodes (see ScheduleDAG*.{cpp,h}). These SUnits nodes are >...

...ving not luck is not great for such a big framework as LLVM :) Shouldn't LLVM use a custom vector implementation for such cases, an implementation that does not invalidate pointers when growing ? I have such an implementation at hand that I'm willing to provide if needed. Regards Amaury Pouly -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100808/4dd2161a/attachment.html>

...blu' of value 'a.bla' Although these issue are not the same, there are similar in the sense that any Value of which the type is a class should have a working subfield lookup and should not require a cast. Except if I'm missing something and there is a real issue underneath. Amaury Pouly 2010/9/1 Chris Lattner <clattner at apple.com> > > On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote: > > > Hello, > > I was fiddling with TableGen (for a use that has nothing to do with a > compiler but it's doesn't matter) and TableGen triggers an assertion f...

On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote: > Hello, > I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): David, can you take a look? This is related...

...the problem is to use !cast with !car but this seems ugly to me: class Bli<string _t> { string t = _t; } class Bla<list<Bli> _bli> : Bli<!cast<Bli>(!car(_bli)).t> { } Is this a bug or is it the wanted behaviour that a cast must be introduced ? Regards Amaury Pouly -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/b043a6a5/attachment.html>

...ssing something and this code is valid or this code has not been executed for a *really* long time now and should be removed or fixed. Unfortunately, I don't know the code enough to fix it if it's necessary that's why I'm seeking for help or reviews on this point :) Regards Amaury Pouly -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100808/1feedada/attachment.html>

...that alias analysis would be much more useful before register allocation when the scheduler still has the opportunity to really move the memory related instructions. Am I missing something ? Wouldn't it be possible to use alias analysis when building the pre-RA schedule graph ? Regards Amaury Pouly -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100722/64d1b53f/attachment.html>

Hi, Did anyone thought of a serialization/deserialization mechanism for DAGs ? Right now i am using the -view-dags functions family.The dot file produced is great for drawing but i find it a bit hard to rebuilt a graph from there(the dot parser are somewhat buggy and much of the useful information is packed in the label element... ) all ideas are welcome... Thanks -------------- next part

...possible to implement those in assembly, I would like to know if there has been some work done to implement this the same way GCC does, or if there is no plan to support this in future ? I am no llvm expert but with some help I think I could implement this if it is a wanted feature. Thanks, Amaury Pouly -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/478171de/attachment.html>