[LLVMbugs] [Bug 390] getFirstTerminator does not work for Sparc
vadve at cs.uiuc.edu
Thu Jul 1 23:18:25 PDT 2004
I agree. It makes sense long-term for MachineBasicBlock to have a
method for finding the first terminator instruction in a basic block of
machine code, and that method should correctly handle targets with and
without delay slots. It's hardly complicated to implement such a
function. If the current function is doing something different, it
should be renamed or if it is x86-specific, perhaps it should be moved
to an x86-specific area.
On Jul 1, 2004, at 11:04 PM, bugzilla-daemon at cs.uiuc.edu wrote:
> gaeke+bugs at uiuc.edu changed:
> What |Removed |Added
> Severity|normal |enhancement
> Status|RESOLVED |REOPENED
> Resolution|WONTFIX |
> ------- Additional Comments From gaeke+bugs at uiuc.edu 2004-07-01 23:04
> I beg to differ...
> getFirstTerminator as it currently stands has built in to it the
> assumption that
> all terminator instructions must be contiguous at the end of the
> machine basic
> block. This is entirely unobvious unless you read the code for the
> method itself.
> If you want to keep it that way -- and that makes sense for
> targets! -- this needs to be documented in some way. (My apologies in
> if I have missed something.)
> In fact, one could reasonably argue that it's broken for blocks which
> have been
> run through the DelaySlotFiller, for example (not just on ordinary
> SparcV9 blocks.)
> In addition, the Sparc backend uses a relatively brittle and even more
> method for finding the first terminator machine instr. I am still of
> the opinion
> that migrating it to use this API (as well as other facets of the
> class, like the machine-CFG) would be an improvement.
> I'm reopening this as an enhancement bug, because although it isn't
> really a
> show-stopper in the short term, it represents an issue that I'd like
> to address in
> the medium term.
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> LLVMbugs mailing list
> LLVMbugs at cs.uiuc.edu
More information about the llvm-bugs