This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Label alignments in shorten_branches


On Mon, Mar 30, 2009 at 5:14 PM, Bernd Schmidt <bernds_cb1@t-online.de> wrote:
> 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?
>
> As I said, it's not just a target-specific problem, it can also happen with
> asm statements since we don't know their exact lengths.

Well, sure.  I expect the code to punt if it sees an asm of course.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]