search for: saomething

...on't require comments in > MachineInstrs. But the information has to be stored somewhere. Ugh. I just found another case I don't think we can synthesize in asmprinter. We mark rematerialized instructions as well so our performance guys don't come and ask us why we didn't hoist saomething out of a loop. :) We're also a bit more expressive in our spill/reload marking. For example, we're mark whether a spill or reload was merged with another instruction and mark copy instructions that were inserted because the spiller could reuse a previous reload. These are all extra thin...

...s in MachineInstrs. But the information has to be stored > > somewhere. > > Ugh. I just found another case I don't think we can synthesize in > asmprinter. We mark rematerialized instructions as well so our performance > guys don't come and ask us why we didn't hoist saomething out of a loop. > :) Here's another question. If we mark StackObjects as spill slots, isn't it possible that stack slot coloring could come along and assign non-spill/reload memory objects to the same slot? If so, it would appear we really do need a flag on MachineInstr to notate all...

On Monday 13 July 2009 15:46, Chris Lattner wrote: > Well sure, but how is that relevant? Just generate llvm.stoppoint and > isel turns them into debug locs. Just because debugloc isn't on > llvm::Instruction doesn't mean you don't get line numbers :). You're right, it's not a big hurdle. > > Ok, here's an example: > > > > movl

...nformation has to be stored >>> somewhere. >> >> Ugh. I just found another case I don't think we can synthesize in >> asmprinter. We mark rematerialized instructions as well so our >> performance >> guys don't come and ask us why we didn't hoist saomething out of a >> loop. >> :) > > Here's another question. If we mark StackObjects as spill slots, > isn't it > possible that stack slot coloring could come along and assign non- > spill/reload > memory objects to the same slot? If so, it would appear we reall...