On 05/19/2015 06:06 PM, Rich Felker wrote:
> And are the above indirect calls/jumps (1983+43) candidates for
> scheduling/hoisting the address load (that's not being done yet), or
> are they the ones the compiler opted not to schedule/hoist? The win
> from relaxation seems small here, but as long a
Hi,
On Wed, 20 May 2015, Rich Felker wrote:
> > of a win that often, outside toy examples. Sure, the compiler can hoist
> > function addresses trivially, but I think it will lead to spilling more
> > often than not, or alternatively the hoisting will be undone by the
> > register allocators r
On Wed, May 20, 2015 at 02:10:41PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Richard Henderson wrote:
>
> > It is. The relaxation that HJ is working on requires that the reads
> > from the got not be hoisted. I'm not especially convinced that what
> > he's working on is a win.
On Wed, May 20, 2015 at 5:10 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Richard Henderson wrote:
>
>> It is. The relaxation that HJ is working on requires that the reads
>> from the got not be hoisted. I'm not especially convinced that what
>> he's working on is a win.
>>
>> With LTO
Hi,
On Tue, 19 May 2015, Richard Henderson wrote:
> It is. The relaxation that HJ is working on requires that the reads
> from the got not be hoisted. I'm not especially convinced that what
> he's working on is a win.
>
> With LTO, the compiler can do the same job that he's attempting in the
On Tue, May 19, 2015 at 05:10:11PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 1:54 PM, Rich Felker wrote:
> > On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> >> > On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> >>
On Tue, May 19, 2015 at 1:54 PM, Rich Felker wrote:
> On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
>> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
>> > On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
>> >> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson
>> >> wro
On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> > On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson
> >> wrote:
> >> > On 05/19/2015 12:06 PM, H.J. Lu wrote:
> >> >> O
On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
>> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson wrote:
>> > On 05/19/2015 12:06 PM, H.J. Lu wrote:
>> >> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson
>> >> wrote:
>> >>>
On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson wrote:
> > On 05/19/2015 12:06 PM, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson
> >> wrote:
> >>> On 05/19/2015 11:06 AM, Rich Felker wrote:
> I'm still
On 05/19/2015 12:35 PM, Rich Felker wrote:
> Why would you recompute it (this requires a fairly expensive call that
> reads or pops its own return address) rather than simply spilling the
> already-computed value and reloading it from the stack?
>
> The only example I can think of where it might m
On 05/19/2015 12:17 PM, H.J. Lu wrote:
>> But my point is that the only time the compiler should present you with the
>> form of indirect branch you're looking for is when there's no place to hoist
>> the load.
>>
>> At which point, is it really worth adding a new relocation to the ABI? Is it
>> r
On Tue, May 19, 2015 at 11:59:00AM -0700, Richard Henderson wrote:
> On 05/19/2015 11:06 AM, Rich Felker wrote:
> > I'm still mildly worried that concerns for supporting
> > relaxation might lead to decisions not to optimize code in ways that
> > would be difficult to relax (e.g. certain types of a
On Tue, May 19, 2015 at 12:11 PM, Richard Henderson wrote:
> On 05/19/2015 12:06 PM, H.J. Lu wrote:
>> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson wrote:
>>> On 05/19/2015 11:06 AM, Rich Felker wrote:
I'm still mildly worried that concerns for supporting
relaxation might lead to
On 05/19/2015 12:06 PM, H.J. Lu wrote:
> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson wrote:
>> On 05/19/2015 11:06 AM, Rich Felker wrote:
>>> I'm still mildly worried that concerns for supporting
>>> relaxation might lead to decisions not to optimize code in ways that
>>> would be difficul
On Tue, May 19, 2015 at 06:01:07PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Jeff Law wrote:
>
> > > > Forget lazy binding. It's dead anyway because serious distros want
> > > > PIE+relro+bindnow+...
> > >
> > > You keep saying this, but I can't help the feeling it's mostly beca
On Tue, May 19, 2015 at 11:59 AM, Richard Henderson wrote:
> On 05/19/2015 11:06 AM, Rich Felker wrote:
>> I'm still mildly worried that concerns for supporting
>> relaxation might lead to decisions not to optimize code in ways that
>> would be difficult to relax (e.g. certain types of address loa
On 05/19/2015 11:06 AM, Rich Felker wrote:
> I'm still mildly worried that concerns for supporting
> relaxation might lead to decisions not to optimize code in ways that
> would be difficult to relax (e.g. certain types of address load
> reordering or hoisting) but I don't understand GCC internals
On Tue, May 19, 2015 at 04:43:53PM +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 15 May 2015, Rich Felker wrote:
>
> > Forget lazy binding. It's dead anyway because serious distros want
> > PIE+relro+bindnow+...
>
> You keep saying this, but I can't help the feeling it's mostly because
> musl do
Hi,
On Tue, 19 May 2015, Jeff Law wrote:
> > > Forget lazy binding. It's dead anyway because serious distros want
> > > PIE+relro+bindnow+...
> >
> > You keep saying this, but I can't help the feeling it's mostly because
> > musl doesn't support it ;-)
>
> FWIW, Red Hat is pushing PIE & parti
On 05/19/2015 08:43 AM, Michael Matz wrote:
Hi,
On Fri, 15 May 2015, Rich Felker wrote:
Forget lazy binding. It's dead anyway because serious distros want
PIE+relro+bindnow+...
You keep saying this, but I can't help the feeling it's mostly because
musl doesn't support it ;-)
FWIW, Red Hat is
Hi,
On Fri, 15 May 2015, Rich Felker wrote:
> Forget lazy binding. It's dead anyway because serious distros want
> PIE+relro+bindnow+...
You keep saying this, but I can't help the feeling it's mostly because
musl doesn't support it ;-)
No, you don't have to use bindnow to get the effects of re
>
> After this message the discussion diverged in the direction of H.J.Lu's
> proposed relaxation scheme involving new type of relocations.
>
> I'm not clear if my patch is actually approved. I'd like to point out that it
> doesn't clash with H.J.Lu's work. It improves codegen by allowing sibca
On Fri, 15 May 2015, Jan Hubicka wrote:
> > >> With -fno-plt, we don't have to reject even direct calls as sibcall
> > >> candidates.
> > >>
> > >> This patch depends on '-fplt' flag that is introduced in another patch.
> > >>
> > >> This patch requires that with -fno-plt all sibcall candidates go
On Sat, May 16, 2015 at 12:03 PM, Rich Felker wrote:
> On Sat, May 16, 2015 at 11:59:56AM -0700, H.J. Lu wrote:
>> On Sat, May 16, 2015 at 7:19 AM, H.J. Lu wrote:
>> > On Fri, May 15, 2015 at 4:49 PM, Rich Felker wrote:
>> >> On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
>> >>> On Fri
On Sat, May 16, 2015 at 11:59:56AM -0700, H.J. Lu wrote:
> On Sat, May 16, 2015 at 7:19 AM, H.J. Lu wrote:
> > On Fri, May 15, 2015 at 4:49 PM, Rich Felker wrote:
> >> On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
> >>> On Fri, May 15, 2015 at 4:30 PM, H.J. Lu wrote:
> >>> > On Fri, M
On Sat, May 16, 2015 at 7:19 AM, H.J. Lu wrote:
> On Fri, May 15, 2015 at 4:49 PM, Rich Felker wrote:
>> On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
>>> On Fri, May 15, 2015 at 4:30 PM, H.J. Lu wrote:
>>> > On Fri, May 15, 2015 at 4:14 PM, H.J. Lu wrote:
>>> >> My relax branch prop
On Fri, May 15, 2015 at 4:49 PM, Rich Felker wrote:
> On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
>> On Fri, May 15, 2015 at 4:30 PM, H.J. Lu wrote:
>> > On Fri, May 15, 2015 at 4:14 PM, H.J. Lu wrote:
>> >> My relax branch proposal works even without LTO.
>> >>
>> >
>> > I will bor
On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
> On Fri, May 15, 2015 at 4:30 PM, H.J. Lu wrote:
> > On Fri, May 15, 2015 at 4:14 PM, H.J. Lu wrote:
> >> My relax branch proposal works even without LTO.
> >>
> >
> > I will borrow GOTPCREL from x86-64 and do
> >
> > [hjl@gnu-6 relax-4]$
On Fri, May 15, 2015 at 04:14:07PM -0700, H.J. Lu wrote:
> On Fri, May 15, 2015 at 4:08 PM, Jan Hubicka wrote:
> > Hello,
> >>
> >> There are codes like
> >>
> >> extern void foo (void);
> >>
> >> void
> >> bar (void)
> >> {
> >> foo ();
> >> }
> >>
> >> Even with LTO, compiler may have to assum
On Fri, May 15, 2015 at 4:30 PM, H.J. Lu wrote:
> On Fri, May 15, 2015 at 4:14 PM, H.J. Lu wrote:
>> My relax branch proposal works even without LTO.
>>
>
> I will borrow GOTPCREL from x86-64 and do
>
> [hjl@gnu-6 relax-4]$ cat b.S
> call *foo@GOTPCREL(%eax)
call *foo@GOTPLT(%eax)
is a better c
On Fri, May 15, 2015 at 4:14 PM, H.J. Lu wrote:
> My relax branch proposal works even without LTO.
>
I will borrow GOTPCREL from x86-64 and do
[hjl@gnu-6 relax-4]$ cat b.S
call *foo@GOTPCREL(%eax)
[hjl@gnu-6 relax-4]$ ./as -32 -o b.o b.S
[hjl@gnu-6 relax-4]$ ./objdump -dwr b.o
b.o: file for
On Fri, May 15, 2015 at 4:08 PM, Jan Hubicka wrote:
> Hello,
>>
>> There are codes like
>>
>> extern void foo (void);
>>
>> void
>> bar (void)
>> {
>> foo ();
>> }
>>
>> Even with LTO, compiler may have to assume foo is external
>> when foo is compiled with LTO.
>
> This is not exactly true if F
Hello,
>
> There are codes like
>
> extern void foo (void);
>
> void
> bar (void)
> {
> foo ();
> }
>
> Even with LTO, compiler may have to assume foo is external
> when foo is compiled with LTO.
This is not exactly true if FOO is defined in other translation unit
compiled with LTO and hidde
On Fri, May 15, 2015 at 1:42 PM, Rich Felker wrote:
> On Fri, May 15, 2015 at 01:35:14PM -0700, H.J. Lu wrote:
>> On Fri, May 15, 2015 at 1:23 PM, Rich Felker wrote:
>> > On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
>> >> With relax branch in 32-bit, there are 2 cases:
>> >>
>> >> 1.
On Fri, May 15, 2015 at 01:35:14PM -0700, H.J. Lu wrote:
> On Fri, May 15, 2015 at 1:23 PM, Rich Felker wrote:
> > On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
> >> With relax branch in 32-bit, there are 2 cases:
> >>
> >> 1. PIC or PIE: We generate
> >>
> >> set up EBX
> >> relax cal
On Fri, May 15, 2015 at 1:23 PM, Rich Felker wrote:
> On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
>> With relax branch in 32-bit, there are 2 cases:
>>
>> 1. PIC or PIE: We generate
>>
>> set up EBX
>> relax call foo@PLT
>>
>> It is almost the same as we do now, except for the relax
On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
> With relax branch in 32-bit, there are 2 cases:
>
> 1. PIC or PIE: We generate
>
> set up EBX
> relax call foo@PLT
>
> It is almost the same as we do now, except for the relax prefix.
> If foo is defined in another shared library or may
On Fri, May 15, 2015 at 12:48 PM, Jan Hubicka wrote:
>> On Fri, May 15, 2015 at 9:27 AM, Alexander Monakov
>> wrote:
>> > Ping? Any comment about this patch?
>> >
>> > On Mon, 4 May 2015, Alexander Monakov wrote:
>> >
>> >> With -fno-plt, we don't have to reject even direct calls as sibcall
>>
> On Fri, May 15, 2015 at 9:27 AM, Alexander Monakov wrote:
> > Ping? Any comment about this patch?
> >
> > On Mon, 4 May 2015, Alexander Monakov wrote:
> >
> >> With -fno-plt, we don't have to reject even direct calls as sibcall
> >> candidates.
> >>
> >> This patch depends on '-fplt' flag that
On Fri, May 15, 2015 at 9:27 AM, Alexander Monakov wrote:
> Ping? Any comment about this patch?
>
> On Mon, 4 May 2015, Alexander Monakov wrote:
>
>> With -fno-plt, we don't have to reject even direct calls as sibcall
>> candidates.
>>
>> This patch depends on '-fplt' flag that is introduced in a
Ping? Any comment about this patch?
On Mon, 4 May 2015, Alexander Monakov wrote:
> With -fno-plt, we don't have to reject even direct calls as sibcall
> candidates.
>
> This patch depends on '-fplt' flag that is introduced in another patch.
>
> This patch requires that with -fno-plt all sibcal
With -fno-plt, we don't have to reject even direct calls as sibcall
candidates.
This patch depends on '-fplt' flag that is introduced in another patch.
This patch requires that with -fno-plt all sibcall candidates go through
prepare_call_address that transforms the call to a GOT lookup.
OK?
43 matches
Mail list logo
