[LLVMbugs] [Bug 390] getFirstTerminator does not work for Sparc

[Vikram Adve]

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.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

On Jul 1, 2004, at 11:04 PM, bugzilla-daemon at cs.uiuc.edu wrote:

> http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=390
>
> 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  
> non-delay-slot
> targets! -- this needs to be documented in some way. (My apologies in  
> advance
> 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  
> unobvious
> 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  
> MachineBasicBlock
> 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
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmbugs