Label alignments in shorten_branches

[Christian BRUEL]

Resent with the patch attached...
It was made from a 4.3.3 base, can relocate to the trunk if needed.

Cheers

Christian

Christian Bruel wrote:
> I had the same problem a while ago, asm_insn_count function just count 
> the number of line separators and assumes the default lengths.
> 
> I added a TARGET_ASM_COUNT macro. Here is in attachement for an 
> implementation for SH that also accounts some of space or align 
> directives. But it is difficult to go further since assembly macros 
> could be more complicated. Anyway, that is already better and should fix 
> your problem. Should be quite target independant.
> Here I assume the instructions lengths were correctly set before 
> computing the insn_current_address.
> 
> Would it be useful to submit it (well, here it is.) ?
> 
> Best Regards
> 
> Christian
> 
> 2009-01-20  Christian Bruel  <christian.bruel@st.com>
> 
>     * final.c (TARGET_ASM_COUNT): Use.
>     * config/sh/sh-protos.h (sh_asm_count): Declared.
>     * config/sh/sh.h (TARGET_ASM_COUNT): Declared.
>     * config/sh/sh.c (sh_asm_count): Defined.
> 
> Richard Guenther wrote:
>> On Mon, Mar 30, 2009 at 4:53 PM, Bernd Schmidt 
>> <bernds_cb1@t-online.de> wrote:
>>> Revision 18357, in 1998, introduced a mechanism to keep track of label
>>> alignments during shorten branches.  It tries to determine the known
>>> alignment at every point in the function, and compute the amount of 
>>> padding
>>> needed at every label.
>>>
>>> The problem is, to do this, we need to know the exact length of every
>>> instruction.  The Blackfin has a few patterns where the length attribute
>>> gives a maximum rather than an exact value, but even if the machine
>>> description is 100% accurate, there is in general no way of knowing the
>>> exact length of an asm statement.
>>>
>>> I have a testcase where the compiler produces an assembly file that 
>>> has an
>>> out-of-range jump, because it thought the label at the start of a 
>>> jump table
>>> (which has an alignment of 4) needs no padding, when in fact it needs 2
>>> bytes of padding.
>>>
>>> Can anyone think of a way to make this code work, or should I just 
>>> post a
>>> patch to mostly revert 18357?
>>
>> Add a target macro TARGET_LIES_WITH_INSN_LENGTH and
>> disable 18357 based on that?
>>
>> Richard.
>>
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: asm_size.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090330/fa5c1a8b/attachment.ksh>