Hi, Lets back up a bit. I'm trying to find hot loops in the program that might include function calls. Any time I find a PC < the last PC, I'm calling that a back edge. So I'm trying to distinguish a back edge of a function call/return from the back edge of a loop. My original plan was to use exclude unconditional branches (which are most likely function calls/returns) from being back-edges.
However, having done a little more research, it appears ARM turns that on its head. Correct me if I'm wrong, but it uses r15 as the PC register, and the programmer is allowed to directly access that on most instructions. For example to return from an function call, instead of the traditional "ret" (an unconditional branch), the programmer (or compiler) can use a move or a load from memory (or others?) to set r15. Neither of these are even branches, let alone traditional "unconditional" branches. So now I'm not sure how much "isCondCtrl" and "isUncondCtrl" are going to help me. I'm trying to find a way to come up with a way of distinguishing function calls and returns from loops using just StaticInst, without having to look at ARM specific instructions. Thanks Andrew Lukefahr [email protected] Open Source, Open Minds On Wed, Feb 9, 2011 at 11:48 PM, Ali Saidi <[email protected]> wrote: > As Gabe said, pretty much every instruction in ARM is conditional so by > that definition there isn't such thing as an unconditional branch. When the > condition is always or unconditional it becomes closer to an unconditional > branch and perhaps we should set the conditional/unconditional flags on the > branches based on that, but as you noticed we don't. Feel free to give it a > try. You should be able to add it to the branches constructor around the > lines that say if (!(condCode == COND_AL || condCode == COND_UC)) { > > Ali > > On Feb 8, 2011, at 12:37 PM, Gabriel Michael Black wrote: > > > Without actually looking at the code, I'm pretty sure those flags just > aren't being set when those instructions are defined. That would be done in > the ISA description files in the arch/arm/isa directory. I don't think > instructions that set R15 (the PC register) are currently being marked as > control instructions. Also whether an instruction is conditional or not is a > fuzzy concept in ARM. They can all be conditional because of predicated > execution, with a few exceptions, but often the condition is "always" which > is effectively unconditional. The current ARM maintainers (Ali and others) > might be better able to help you. I might implement something too, but I > can't test changes as well as they can and might not have time for a while. > > > > Gabe > > > > Quoting Andrew Lukefahr <[email protected]>: > > > >> Hi, > >> > >> I'm trying to determine when a StaticInst is a conditional vs > unconditional > >> branch using the ARM ISA. The StaticInstBase class has a isControl() > >> function that seems to work, but the isCondCtrl() and isUncondCtrl() do > >> not. Further grep'ing revealed that in my > build/ARM_SE/arch/arm/decoder.cc > >> file, I have lots of "flags[IsControl]=true;" statements, but none for > the > >> CondCtrl and UncondCtrl. > >> > >> So, > >> 1) Is there a better way to decide if an inst is a conditional vs > >> unconditional branch? > >> 2) If not, where would I add cond/uncond flags to the ISA? > >> > >> Thanks > >> > >> Andrew Lukefahr > >> [email protected] > >> > >> Open Source, Open Minds > >> > > > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
