On Wed, Jun 10, 2015 at 11:24:05AM -0700, Andy Lutomirski wrote:
> Slightly off-topic, but this reminds me: when writing inline asm that
> needs to push to the stack (for whatever reason), it's incredibly
> messy to get the annotations right -- they're different depending on
> whether the previous
On Wed, Jun 10, 2015 at 12:38:32PM -0700, Andy Lutomirski wrote:
> On Wed, Jun 10, 2015 at 12:36 PM, Josh Poimboeuf wrote:
> > On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
> >> Josh Poimboeuf writes:
> >>
> >> > On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> >> >> >
On Wed, Jun 10, 2015 at 11:41:43AM -0700, Andi Kleen wrote:
> Josh Poimboeuf writes:
> >
> > If you're wanting something like -freorder-blocks-and-partition for asm
> > code, maybe we could implement something analagous to the
> > likely()/unlikely() macros, to allow the hot and cold portions to
On Wed, Jun 10, 2015 at 12:36 PM, Josh Poimboeuf wrote:
> On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
>> Josh Poimboeuf writes:
>>
>> > On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
>> >> > > > - duplicate the destination code inside the function
>> >> > > > -
On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
> Josh Poimboeuf writes:
>
> > On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> >> > > > - duplicate the destination code inside the function
> >> > > > - convert the jump to a call
> >> > >
> >> > > That all won't work
Josh Poimboeuf writes:
>
> If you're wanting something like -freorder-blocks-and-partition for asm
> code, maybe we could implement something analagous to the
> likely()/unlikely() macros, to allow the hot and cold portions to be
> placed into different sections. (I could then teach asmvalidate
Josh Poimboeuf writes:
> On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
>> > > > - duplicate the destination code inside the function
>> > > > - convert the jump to a call
>> > >
>> > > That all won't work for a lot of cases.
>> >
>> > Hm, could you give an example?
>>
>> Just a
On Wed, Jun 10, 2015 at 5:06 AM, Josh Poimboeuf wrote:
> The previous version of this patch set was named "Compile-time stack
> frame pointer validation". I changed the subject from "frame pointer
> validation" to "asm code validation" because the focus of the patch set
> has changed to be less
On Wed, Jun 10, 2015 at 10:31:55AM -0500, Josh Poimboeuf wrote:
> On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> > It's not needed, but it's an optimization to optimize icache usage.
> > It is optional (-freorder-blocks-and-partition)
> >
> > In this case gcc splits the function
On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> > > > - duplicate the destination code inside the function
> > > > - convert the jump to a call
> > >
> > > That all won't work for a lot of cases.
> >
> > Hm, could you give an example?
>
> Just a standard *_user exception handler.
> > > - duplicate the destination code inside the function
> > > - convert the jump to a call
> >
> > That all won't work for a lot of cases.
>
> Hm, could you give an example?
Just a standard *_user exception handler.
>
> Well, I don't see how that's really a logical conclusion.
What's
On Wed, Jun 10, 2015 at 04:11:04PM +0200, Andi Kleen wrote:
> > In most cases there are ways to keep the optimizations. For example:
> >
> > - grow the function bounds to keep the jump internal
>
> So you mean moving it after the ret? That still means icache bloat.
No, in most cases it just
On Wed, Jun 10, 2015 at 03:42:41PM +0200, Pavel Machek wrote:
> On Wed 2015-06-10 07:06:08, Josh Poimboeuf wrote:
> > The previous version of this patch set was named "Compile-time stack
> > frame pointer validation". I changed the subject from "frame pointer
> > validation" to "asm code
> In most cases there are ways to keep the optimizations. For example:
>
> - grow the function bounds to keep the jump internal
So you mean moving it after the ret? That still means icache bloat.
> - duplicate the destination code inside the function
> - convert the jump to a call
That all
On Wed, Jun 10, 2015 at 03:08:14PM +0200, Andi Kleen wrote:
>
> > 2. Each callable function must never leave its own bounds (i.e. with a
> >jump to outside the function) except when returning.
>
> That prevents a lot of optimizations with out of line code.
In most cases there are ways to
On Wed 2015-06-10 07:06:08, Josh Poimboeuf wrote:
> The previous version of this patch set was named "Compile-time stack
> frame pointer validation". I changed the subject from "frame pointer
> validation" to "asm code validation" because the focus of the patch set
> has changed to be less frame
> 2. Each callable function must never leave its own bounds (i.e. with a
>jump to outside the function) except when returning.
That prevents a lot of optimizations with out of line code.
In fact even gcc with the right options can generate code that violates
this. Standard Linux
On Wed, Jun 10, 2015 at 07:06:08AM -0500, Josh Poimboeuf wrote:
> There are still a lot of outstanding warnings (which I'll paste as a
> reply to this email). Once those are all cleaned up, we can change the
> warnings to build errors and change the default to
> CONFIG_ASM_VALIDATION=y so the asm
The previous version of this patch set was named "Compile-time stack
frame pointer validation". I changed the subject from "frame pointer
validation" to "asm code validation" because the focus of the patch set
has changed to be less frame pointer-focused and more asm-focused. I
also renamed the
The previous version of this patch set was named Compile-time stack
frame pointer validation. I changed the subject from frame pointer
validation to asm code validation because the focus of the patch set
has changed to be less frame pointer-focused and more asm-focused. I
also renamed the tool
On Wed, Jun 10, 2015 at 07:06:08AM -0500, Josh Poimboeuf wrote:
There are still a lot of outstanding warnings (which I'll paste as a
reply to this email). Once those are all cleaned up, we can change the
warnings to build errors and change the default to
CONFIG_ASM_VALIDATION=y so the asm
2. Each callable function must never leave its own bounds (i.e. with a
jump to outside the function) except when returning.
That prevents a lot of optimizations with out of line code.
In fact even gcc with the right options can generate code that violates
this. Standard Linux
On Wed, Jun 10, 2015 at 03:08:14PM +0200, Andi Kleen wrote:
2. Each callable function must never leave its own bounds (i.e. with a
jump to outside the function) except when returning.
That prevents a lot of optimizations with out of line code.
In most cases there are ways to keep the
In most cases there are ways to keep the optimizations. For example:
- grow the function bounds to keep the jump internal
So you mean moving it after the ret? That still means icache bloat.
- duplicate the destination code inside the function
- convert the jump to a call
That all won't
On Wed, Jun 10, 2015 at 03:42:41PM +0200, Pavel Machek wrote:
On Wed 2015-06-10 07:06:08, Josh Poimboeuf wrote:
The previous version of this patch set was named Compile-time stack
frame pointer validation. I changed the subject from frame pointer
validation to asm code validation because
On Wed 2015-06-10 07:06:08, Josh Poimboeuf wrote:
The previous version of this patch set was named Compile-time stack
frame pointer validation. I changed the subject from frame pointer
validation to asm code validation because the focus of the patch set
has changed to be less frame
On Wed, Jun 10, 2015 at 04:11:04PM +0200, Andi Kleen wrote:
In most cases there are ways to keep the optimizations. For example:
- grow the function bounds to keep the jump internal
So you mean moving it after the ret? That still means icache bloat.
No, in most cases it just means
- duplicate the destination code inside the function
- convert the jump to a call
That all won't work for a lot of cases.
Hm, could you give an example?
Just a standard *_user exception handler.
Well, I don't see how that's really a logical conclusion.
What's special about
On Wed, Jun 10, 2015 at 10:31:55AM -0500, Josh Poimboeuf wrote:
On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
It's not needed, but it's an optimization to optimize icache usage.
It is optional (-freorder-blocks-and-partition)
In this case gcc splits the function into two
On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
- duplicate the destination code inside the function
- convert the jump to a call
That all won't work for a lot of cases.
Hm, could you give an example?
Just a standard *_user exception handler.
I'm afraid I don't
On Wed, Jun 10, 2015 at 12:38:32PM -0700, Andy Lutomirski wrote:
On Wed, Jun 10, 2015 at 12:36 PM, Josh Poimboeuf jpoim...@redhat.com wrote:
On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
Josh Poimboeuf jpoim...@redhat.com writes:
On Wed, Jun 10, 2015 at 05:04:12PM +0200,
On Wed, Jun 10, 2015 at 11:41:43AM -0700, Andi Kleen wrote:
Josh Poimboeuf jpoim...@redhat.com writes:
If you're wanting something like -freorder-blocks-and-partition for asm
code, maybe we could implement something analagous to the
likely()/unlikely() macros, to allow the hot and cold
On Wed, Jun 10, 2015 at 11:24:05AM -0700, Andy Lutomirski wrote:
Slightly off-topic, but this reminds me: when writing inline asm that
needs to push to the stack (for whatever reason), it's incredibly
messy to get the annotations right -- they're different depending on
whether the previous
On Wed, Jun 10, 2015 at 12:36 PM, Josh Poimboeuf jpoim...@redhat.com wrote:
On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
Josh Poimboeuf jpoim...@redhat.com writes:
On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
- duplicate the destination code inside the
On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
Josh Poimboeuf jpoim...@redhat.com writes:
On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
- duplicate the destination code inside the function
- convert the jump to a call
That all won't work for a lot
Josh Poimboeuf jpoim...@redhat.com writes:
On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
- duplicate the destination code inside the function
- convert the jump to a call
That all won't work for a lot of cases.
Hm, could you give an example?
Just a standard
Josh Poimboeuf jpoim...@redhat.com writes:
If you're wanting something like -freorder-blocks-and-partition for asm
code, maybe we could implement something analagous to the
likely()/unlikely() macros, to allow the hot and cold portions to be
placed into different sections. (I could then
On Wed, Jun 10, 2015 at 5:06 AM, Josh Poimboeuf jpoim...@redhat.com wrote:
The previous version of this patch set was named Compile-time stack
frame pointer validation. I changed the subject from frame pointer
validation to asm code validation because the focus of the patch set
has changed to
38 matches
Mail list logo
