search for: subpasses

On Aug 5, 2004, at 8:11 PM, Chris Lattner wrote: > > Sure, you can do that. Just use F->getParent() to get to the Module. D'oh. OK, so I can do what I need with a hack for now. >> Also, out of curiosity, why the stateless restriction - is it because >> passes may someday be run in parallel? > > Yup, exactly. That and we want to be able to make multiple instances

On Mon, 9 Aug 2004, Michael McCracken wrote: > On Aug 5, 2004, at 8:11 PM, Chris Lattner wrote: > > Sure, you can do that. Just use F->getParent() to get to the Module. > > D'oh. OK, so I can do what I need with a hack for now. Ok. > > We have no problem with people asking questions. :) The PassManager > > is actually do for a rewrite. The current

On 4/24/2013 8:05 PM, Nadav Rotem wrote: > > Everything. This includes all of the custom lowering code for all of the > targets, all of dagcombine, and maybe all of the patterns in the TD files. I may have missed the discussion, but why are we trying to move away from the SelectionDAG? Are there specific problems that we don't want to fix or live with? If so, what are they?

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of instructions and use bundles and maybe also PredicateInstruction(), which is employed also in IfConversion.cpp. More exactly I'm trying to use a pseudo-instruction that will...

...legalize patch I attached at the beginning of this thread doesn't need a worklist or a sort; it just walks down the instructions in each block, which is handy. Another reason why people don't like SelectionDAG framework is that it's slow. It's effectively one big pass (with several subpasses), and it consistently scores among the top of the compile time profiles. At one time, I did a bunch of work to try to make it faster, though I don't think I did all the right things. I think there are still several opportunities to speed it up significantly. However, some of the problems are pr...

On Thu, 5 Aug 2004, Michael McCracken wrote: > > You're right that FunctionPass's are not supposed to have state > > (something that many people overlook :) ), however, for now, nothing > > will break if it does have state, and this is really the only way > > around this. > > I'm not sure if I can do this. The pass I'm writing is writing info >

Hello. For my back end for the Connex SIMD research processor I want to implement conditional blocks (I guess the better term is predicated blocks). Predicated blocks are bordered by two instructions WHEREEQ (or WHERELT, etc) and ENDWHERE. For example, the following code executes the instructions inside the WHERE block only for the lanes where R0 == R1: EQ R0, R1;

On Apr 24, 2013, at 5:53 PM, Reed Kotler <rkotler at mips.com> wrote: > One question : > > "In the spirit of the (long-term) intent to migrate away from the > SelectionDAG framework" > > .. is this meant in general or just in respect to legalization? Everything. This includes all of the custom lowering code for all of the targets, all of dagcombine, and maybe

On Aug 9, 2004, at 1:46 PM, Chris Lattner wrote: >> Well, I took a look at it a bit over the weekend. I am probably not >> the >> right person to do the complete rewrite, for instance reworking the >> Pass class hierarchy doesn't sound like something I'd want to do. Just >> getting to this point has been a bit of an education in real C++. > > Ok, fair

On Aug 5, 2004, at 5:30 PM, Chris Lattner wrote: > On Thu, 5 Aug 2004, Michael McCracken wrote: > >> Hi, I have a hopefully quick question. I'm writing a Pass that needs >> to >> see a whole module at a time and keep some state, so I subclassed >> Pass. >> However, I want to be able to see the Loops in each Function. Roughly, > > ok. > >>

> This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep > from introducing additional observable side-effects, and it's clear that whatever did this did not account > for floating point exception. That’s a very reasonable statement, but I’m not sure it corresponds to the way we have typically approached this sort of problem. In