This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: RFC: PATCH: PR gas/12049: Unnecessary relaxation


On Mon, Oct 18, 2010 at 6:25 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Oct 17, 2010 at 10:32 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Sun, Oct 17, 2010 at 8:35 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Sun, Oct 17, 2010 at 6:32 PM, Alan Modra <amodra@gmail.com> wrote:
>>>> On Sat, Oct 16, 2010 at 03:28:50PM -0700, H.J. Lu wrote:
>>>>> 1. Set address for each frag.
>>>>> 2. Relax and update address for each frag. ?For rs_machine_dependent
>>>>> frag, if its size grows with forward reference, update fr_address for
>>>>> all successive frags.
>>>>> 3. If stretched, goto 2.
>>>>>
>>>>> Does it make any senses?
>>>>
>>>> No it does not. ?The frag loop here is already two deep in loops (loop
>>>> until nothing changed this segment, and loop until nothing changed in
>>>> all segments). ?You've just made the innermost loop over frags
>>>> O(n**2). ?I think that is way too expensive.
>>>
>>> We can limit the new one to the first pass only.
>>>
>>>> A possible fix for your testcase is to allow relax_frag to shrink
>>>> rs_machine_dependent frags, rather than just grow them as it does at
>>>> the moment.
>>>>
>>>
>>> I tried it and it doesn't work. The problem is
>>>
>>> ? ? ? .fill 14, 1, 0x90
>>> ? ? ? jmp ? ? .LBB1_23 ? <- frag 1
>>> ? ? ? .fill 14, 1, 0x90
>>> ? ? ? jmp ? ? .LBB1_23 ?<- frag 2
>>> ? ? ? .fill 18, 1, 0x90
>>> ? ? ? .align ?16, 0x90 ? ?<- frag 3
>>> ? ? ? .fill 96, 1, 0x90
>>> .LBB1_23:
>>>
>>> After frag 1 is grown by 4 bytes, we may not
>>> shrink frag 2 unless the address of frag 3
>>> is adjusted first, which is what my patch does.
>>>
>>
>> Here is the updated patch to do it only for the first iteration.
>>
>>
>
> This patch limits it to the first iteration of the first pass.
>

I tried it on gcc trunk at revision 165633 with i686-linux:

1. Reference assembler:

Bootstrap:

nohup.165633:3266.57user 337.45system 21:07.86elapsed 284%CPU
(0avgtext+0avgdata 0maxresident)k

"make check":

nohup.165633:6963.06user 2752.99system 48:49.64elapsed 331%CPU
(0avgtext+0avgdata 0maxresident)k

2. Fixed assembler:

Bootstrap:

nohup.out:3399.34user 338.88system 22:04.90elapsed 282%CPU
(0avgtext+0avgdata 0maxresident)k

"make check":

nohup.out:6455.17user 2731.98system 47:57.21elapsed 319%CPU
(0avgtext+0avgdata 0maxresident)k

The differences are just noise.


-- 
H.J.


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