H. Peter Anvin wrote:
> On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
>> If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
>> then certainly coming up with a new gcc switch and new profiling ABI is
>> desirable. -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
>>
On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
>
> If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
> then certainly coming up with a new gcc switch and new profiling ABI is
> desirable. -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
> makes code on these regis
On 11/24/2009 09:30 AM, Steven Rostedt wrote:
>
> For other archs, Linus showed some examples:
>
> http://lkml.org/lkml/2009/11/19/349
>
Yes; the key here is that the ABI-defined entry state is readily
mappable onto the state on entry to the __fentry__ function.
-hpa
--
H. Peter Anvi
On Wed, Nov 25, 2009 at 04:44:52PM +0100, Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
> > On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> >
> > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > > you should compile your code with -maccumulate-outgoing-args, and
> > >
* Thomas Gleixner wrote:
> On Wed, 25 Nov 2009, Ingo Molnar wrote:
> > * Thomas Gleixner wrote:
> >
> > > On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> > >
> > > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > > > you should compile your code with -maccumulate-outgoin
On Wed, 25 Nov 2009, Ingo Molnar wrote:
> * Thomas Gleixner wrote:
>
> > On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> >
> > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > > you should compile your code with -maccumulate-outgoing-args, and
> > > > > there's
> > > > > n
* Thomas Gleixner wrote:
> On Tue, 24 Nov 2009, Jakub Jelinek wrote:
>
> > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > you should compile your code with -maccumulate-outgoing-args, and
> > > > there's
> > > > no need to use -mtune=generic. Is that right?
> > >
>
On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > you should compile your code with -maccumulate-outgoing-args, and there's
> > > no need to use -mtune=generic. Is that right?
> >
> > Seems to work. What other side effects has that
On 11/24/2009 09:12 AM, Andrew Haley wrote:
>>
>> If we're changing gcc anyway, then let's add the option of intercepting
>> the function at the point where the machine state is well-defined by
>> ABI, which is before the function stack frame is set up.
>
> Hmm. On the x86 I suppose we could just
On Tue, 2009-11-24 at 17:12 +, Andrew Haley wrote:
> H. Peter Anvin wrote:
> > If we're changing gcc anyway, then let's add the option of intercepting
> > the function at the point where the machine state is well-defined by
> > ABI, which is before the function stack frame is set up.
>
> Hmm.
H. Peter Anvin wrote:
> On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
>>> space for arguments of the callee with most arguments in the prologue, using
>>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) et
Ross Ridge wrote:
> Andrew Haley writes:
>> Alright. So, it is possible in theory for gcc to generate code that
>> only uses -maccumulate-outgoing-args when it needs to realign SP.
>> And, therefore, we could have a nice option for the kernel: one with
>> (mostly) good code density and never gener
Andrew Haley writes:
>Alright. So, it is possible in theory for gcc to generate code that
>only uses -maccumulate-outgoing-args when it needs to realign SP.
>And, therefore, we could have a nice option for the kernel: one with
>(mostly) good code density and never generates the bizarre code
>seque
On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>
>> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
>> space for arguments of the callee with most arguments in the prologue, using
>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
>> and the stack poin
Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote:
>> Jakub Jelinek wrote:
>>> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> you should compile your code with -maccumulate-outgoing-args, and there's
> no need to use -mtune=generic. Is
On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote:
> Jakub Jelinek wrote:
> > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> >>> you should compile your code with -maccumulate-outgoing-args, and there's
> >>> no need to use -mtune=generic. Is that right?
> >> Seems t
Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
>>> you should compile your code with -maccumulate-outgoing-args, and there's
>>> no need to use -mtune=generic. Is that right?
>> Seems to work. What other side effects has that ?
>
> Faster code, significant
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > you should compile your code with -maccumulate-outgoing-args, and there's
> > no need to use -mtune=generic. Is that right?
>
> Seems to work. What other side effects has that ?
Faster code, significant increase in code size th
On Tue, 24 Nov 2009, Andrew Haley wrote:
> H.J. Lu wrote:
> > On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote:
> >> H.J. Lu wrote:
> >>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
> Steven Rostedt wrote:
> > Ingo, Thomas and Linus,
> >
> > I know Thomas did a patch
H.J. Lu wrote:
> On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote:
>> H.J. Lu wrote:
>>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc
On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote:
> H.J. Lu wrote:
>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
>>> Steven Rostedt wrote:
Ingo, Thomas and Linus,
I know Thomas did a patch to force the -mtune=generic, but just in case
gcc decides to do something
H.J. Lu wrote:
> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
>> Steven Rostedt wrote:
>>> Ingo, Thomas and Linus,
>>>
>>> I know Thomas did a patch to force the -mtune=generic, but just in case
>>> gcc decides to do something crazy again, this patch will catch it.
>>>
>>> Should we try t
On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
> Steven Rostedt wrote:
>> Ingo, Thomas and Linus,
>>
>> I know Thomas did a patch to force the -mtune=generic, but just in case
>> gcc decides to do something crazy again, this patch will catch it.
>>
>> Should we try to get this in now?
>
> I
* Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in
> case gcc decides to do something crazy again, this patch will catch
> it.
>
> Should we try to get this in now?
Very nice example of defensive coding - i like this. I'v
On 11/20/2009 11:46 AM, Steven Rostedt wrote:
>
> Yes a gcc test suite will help new instances of gcc. But we need to
> worry about the instances of gcc that people have on their desktops now.
> This test case will catch the discrepancy between gcc and the function
> graph tracer. I'm not 100% con
On Fri, 2009-11-20 at 19:35 +, Andrew Haley wrote:
> Steven Rostedt wrote:
> > Ingo, Thomas and Linus,
> >
> > I know Thomas did a patch to force the -mtune=generic, but just in case
> > gcc decides to do something crazy again, this patch will catch it.
> >
> > Should we try to get this in no
Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc decides to do something crazy again, this patch will catch it.
>
> Should we try to get this in now?
I'm sure this makes sense, but a gcc test case would be even bett
On 11/20/2009 09:00 AM, Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc decides to do something crazy again, this patch will catch it.
>
> Should we try to get this in now?
>
Sounds like a very good idea to me.
Ingo, Thomas and Linus,
I know Thomas did a patch to force the -mtune=generic, but just in case
gcc decides to do something crazy again, this patch will catch it.
Should we try to get this in now?
-- Steve
On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote:
> commit c7715fb611c69ac4b7f722a
This touches the Makefile scripts. I forgot to CC kbuild and Sam.
-- Steve
On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote:
> Ingo,
>
> Not sure if this is too much for this late in the -rc game, but it finds
> the gcc bug at build time, and we don't need to disable function graph
> trac
Ingo,
Not sure if this is too much for this late in the -rc game, but it finds
the gcc bug at build time, and we don't need to disable function graph
tracer for all i386 builds.
This is built on my last urgent repo pull request.
Please pull the latest tip/tracing/urgent-2 tree, which can be fou
31 matches
Mail list logo
