search for: getexit

https://bugs.freedesktop.org/show_bug.cgi?id=96274 Bug ID: 96274 Summary: [NVC0] Failure when compiling compute shader: Assertion `bb->getFirst()->serial <= bb->getExit()->serial' failed Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at lists.freedesktop.org...

...terator" that can iterate all the basic blocks in the region plus the exit at once. What I usually do, under this kind of situation, is to define a std::vector of basicblocks, push all the basic blocks in the region using block_iterator in a for loop. And then, at the end, push_back(region->getExit()). > > An example, where it is beneficial to use the block after the region as to > define a region is the following: > > IF-1 > / \ > | IF-2 > | / \ > | | | > \ | / > \ | / > \|/ > END > > Here, we would...

...ent way to > > dicectly get that information? > > Given a function you can always use Function::getEntryBlock() to get the > entry block. You need to scan the function to get the returning nodes. You could also use UnifyExitNode (a pass in analysis) to unify the exits, and then use getExit() to get the exit node. -anand

https://bugs.freedesktop.org/show_bug.cgi?id=90887 Bug ID: 90887 Summary: PhiMovesPass in register allocator broken Product: Mesa Version: git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

Dear LLVM, I want to know, given a function, How do I know which block is entry block, which blocks are exit blocks? Is there any efficient way to dicectly get that information?

Hi Tobias, Thanks so much for the quick response. Your approach fixes the issue. On a bigger context, would it make more sense to make the region exit part of the region? For example, a while loop gets lowered down to LLVM IR contains while.cond, while.body and while.end. If one tries to use RegionInfo as a substitute for structural analysis, she might think while.end should belong to

Most of codegen is already FP64-ready. There are a few edge-cases that I ran into, many of which can apply even to non-fp64-enabled programs (although the double-wide registers are not very common without fp64). I've yet to give this a full piglit run, but wanted to send these out in case someone wanted to comment. They do not depend on the preliminary core fp64 work. Ilia Mirkin (5):