Quoting Uros Bizjak :
On Sun, Aug 4, 2013 at 2:34 AM, NightStrike wrote:
On Mon, Jul 22, 2013 at 5:22 AM, Igor Zamyatin wrote:
Hi All!
Unfortunately now the compiler generates wrong code for i686 target
when options -O3 and -flto are used. It started more than a month ago
and reflected in P
Hi,
I'm looking for some help understanding how BIT_FIELD_REFs work with big-endian.
Vector subscripts in this example:
#define vector __attribute__((vector_size(sizeof(int)*4) ))
typedef int vec vector;
int foo(vec a)
{
return a[0];
}
gets lowered into array accesses by c-typeck.c
;; Fu
Sorry for the long mail and for what's probably an FAQ. I did try to find
an answer without bothering the list... (and showing my ignorance so much :-))
At the moment, the s390 backend treats all atomic loads as simple loads
and only uses serialisation instructions for atomic stores. I just want
It is the intent for all_ones_mask_p to return true when 64 bits of ones in an
unsigned type of width 64 when size is 64, right? Currently the code uses a
signed type for tmask, which sets the upper bits to 1, when the value includes
the sign bit set and the equality code does check all 128 bit
[ sent to both Linux kernel mailing list and to gcc list ]
I was looking at some of the old code I still have marked in my TODO
list, that I never pushed to get mainlined. One of them is to move trace
point logic out of the fast path to get rid of the stress that it
imposes on the icache.
Almost
On 08/05/2013 09:55 AM, Steven Rostedt wrote:
>
> Almost a full year ago, Mathieu suggested something like:
>
> if (unlikely(x)) __attribute__((section(".unlikely"))) {
> ...
> } else __attribute__((section(".likely"))) {
> ...
> }
>
> https://lkml.org/lkml/2012/8/9/658
>
> Whic
On Mon, Aug 5, 2013 at 9:55 AM, Steven Rostedt wrote:
>
> Almost a full year ago, Mathieu suggested something like:
>
> if (unlikely(x)) __attribute__((section(".unlikely"))) {
> ...
> } else __attribute__((section(".likely"))) {
> ...
> }
It's almost certainly a horrible idea.
F
On Mon, Aug 5, 2013 at 10:12 AM, Linus Torvalds
wrote:
>
> Secondly, you don't want a separate section anyway for any normal
> kernel code, since you want short jumps if possible
Just to clarify: the short jump is important regardless of how
unlikely the code you're jumping is, since even if you'
On Mon, Aug 5, 2013 at 11:44 AM, Mike Stump wrote:
> It is the intent for all_ones_mask_p to return true when 64 bits of ones in
> an unsigned type of width 64 when size is 64, right? Currently the code uses
> a signed type for tmask, which sets the upper bits to 1, when the value
> includes t
On Mon, 2013-08-05 at 10:02 -0700, H. Peter Anvin wrote:
> > if (x) __attibute__((section(".foo"))) {
> > /* do something */
> > }
> >
>
> One concern I have is how this kind of code would work when embedded
> inside a function which already has a section attribute. This could
> easily caus
On Mon, 2013-08-05 at 10:12 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 9:55 AM, Steven Rostedt wrote:
> First off, we have very few things that are *so* unlikely that they
> never get executed. Putting things in a separate section would
> actually be really bad.
My main concern is wit
On Mon, 2013-08-05 at 13:55 -0400, Steven Rostedt wrote:
> The difference between this and the
> "section" hack I suggested, is that this would use a "call"/"ret" when
> enabled instead of a "jmp"/"jmp".
I wonder if this is what Kris Kross meant in their song?
/me goes back to work...
-- Steve
On 08/05/2013 10:55 AM, Steven Rostedt wrote:
>
> Well, as tracepoints are being added quite a bit in Linux, my concern is
> with the inlined functions that they bring. With jump labels they are
> disabled in a very unlikely way (the static_key_false() is a nop to skip
> the code, and is dynamical
On Mon, Aug 5, 2013 at 10:55 AM, Steven Rostedt wrote:
>
> My main concern is with tracepoints. Which on 90% (or more) of systems
> running Linux, is completely off, and basically just dead code, until
> someone wants to see what's happening and enables them.
The static_key_false() approach with
On Mon, 2013-08-05 at 11:17 -0700, H. Peter Anvin wrote:
> On 08/05/2013 10:55 AM, Steven Rostedt wrote:
> >
> > Well, as tracepoints are being added quite a bit in Linux, my concern is
> > with the inlined functions that they bring. With jump labels they are
> > disabled in a very unlikely way (t
On Mon, Aug 5, 2013 at 11:20 AM, Linus Torvalds
wrote:
>
> The static_key_false() approach with minimal inlining sounds like a
> much better approach overall.
Sorry, I misunderstood your thing. That's actually what you want that
section thing for, because right now you cannot generate the argumen
On 08/05/2013 11:23 AM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 11:17 -0700, H. Peter Anvin wrote:
>> On 08/05/2013 10:55 AM, Steven Rostedt wrote:
>>>
>>> Well, as tracepoints are being added quite a bit in Linux, my concern is
>>> with the inlined functions that they bring. With jump labels
On 08/05/2013 11:20 AM, Linus Torvalds wrote:
>
> Of course, it would be good to optimize static_key_false() itself -
> right now those static key jumps are always five bytes, and while they
> get nopped out, it would still be nice if there was some way to have
> just a two-byte nop (turning into
On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
wrote:
>
> Ugh. I can see the attraction of your section thing for that case, I
> just get the feeling that we should be able to do better somehow.
Hmm.. Quite frankly, Steven, for your use case I think you actually
want the C goto *labels* associat
On 08/05/2013 11:34 AM, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
> wrote:
>>
>> Ugh. I can see the attraction of your section thing for that case, I
>> just get the feeling that we should be able to do better somehow.
>
> Hmm.. Quite frankly, Steven, for your use ca
On Mon, 2013-08-05 at 11:20 -0700, Linus Torvalds wrote:
> Of course, it would be good to optimize static_key_false() itself -
> right now those static key jumps are always five bytes, and while they
> get nopped out, it would still be nice if there was some way to have
> just a two-byte nop (turn
On Mon, 2013-08-05 at 11:29 -0700, H. Peter Anvin wrote:
> Traps nest, that's why there is a stack. (OK, so you don't want to take
> the same trap inside the trap handler, but that code should be very
> limited.) The trap instruction just becomes very short, but rather
> slow, call-return.
>
>
On Mon, Aug 5, 2013 at 11:39 AM, Steven Rostedt wrote:
>
> I had patches that did exactly this:
>
> https://lkml.org/lkml/2012/3/8/461
>
> But it got dropped for some reason. I don't remember why. Maybe because
> of the complexity?
Ugh. Why the crazy update_jump_label script stuff? I'd go "Eww"
On 08/05/2013 11:49 AM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 11:29 -0700, H. Peter Anvin wrote:
>
>> Traps nest, that's why there is a stack. (OK, so you don't want to take
>> the same trap inside the trap handler, but that code should be very
>> limited.) The trap instruction just beco
On Mon, Aug 5, 2013 at 11:51 AM, H. Peter Anvin wrote:
>>
>> Also, how would you pass the parameters? Every tracepoint has its own
>> parameters to pass to it. How would a trap know what where to get "prev"
>> and "next"?
>
> How do you do that now?
>
> You have to do an IP lookup to find out what
On Mon, 2013-08-05 at 11:34 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
> wrote:
> >
> > Ugh. I can see the attraction of your section thing for that case, I
> > just get the feeling that we should be able to do better somehow.
>
> Hmm.. Quite frankly, Steven, f
Steven Rostedt writes:
Can't you just use -freorder-blocks-and-partition?
This should already partition unlikely blocks into a
different section. Just a single one of course.
FWIW the disadvantage is that multiple code sections tends
to break various older dwarf unwinders, as it needs
dwarf3 la
On Mon, 2013-08-05 at 11:51 -0700, H. Peter Anvin wrote:
> On 08/05/2013 11:49 AM, Steven Rostedt wrote:
> > On Mon, 2013-08-05 at 11:29 -0700, H. Peter Anvin wrote:
> >
> >> Traps nest, that's why there is a stack. (OK, so you don't want to take
> >> the same trap inside the trap handler, but th
On Mon, 2013-08-05 at 12:04 -0700, Andi Kleen wrote:
> Steven Rostedt writes:
>
> Can't you just use -freorder-blocks-and-partition?
Yeah, I'm familiar with this option.
>
> This should already partition unlikely blocks into a
> different section. Just a single one of course.
>
> FWIW the dis
On Mon, Aug 5, 2013 at 12:04 PM, Andi Kleen wrote:
> Steven Rostedt writes:
>
> Can't you just use -freorder-blocks-and-partition?
>
> This should already partition unlikely blocks into a
> different section. Just a single one of course.
That's horrible. Not because of dwarf problems, but exactl
On Mon, Aug 5, 2013 at 12:16 PM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 12:04 -0700, Andi Kleen wrote:
>> Steven Rostedt writes:
>>
>> Can't you just use -freorder-blocks-and-partition?
>
> Yeah, I'm familiar with this option.
>
This option works best with FDO. FDOed linux kernel rocks
On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:39 AM, Steven Rostedt wrote:
> >
> > I had patches that did exactly this:
> >
> > https://lkml.org/lkml/2012/3/8/461
> >
> > But it got dropped for some reason. I don't remember why. Maybe because
> > of the comp
On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
> wrote:
> >
> > Ugh. I can see the attraction of your section thing for that case, I
> > just get the feeling that we should be able to do better somehow.
>
> Hmm.. Quite frankly, St
* Linus Torvalds (torva...@linux-foundation.org) wrote:
[...]
> With two-byte jumps, you'd still get the I$ fragmentation (the
> argument generation and the call and the branch back would all be in
> the same code segment as the hot code), but that would be offset by
> the fact that at least the ho
On Mon, Aug 5, 2013 at 12:40 PM, Marek Polacek wrote:
>
> FWIW, we also support hot/cold attributes for labels, thus e.g.
>
> if (bar ())
> goto A;
> /* ... */
> A: __attribute__((cold))
> /* ... */
>
> I don't know whether that might be useful for what you want or not though...
Steve?
On 08/05/2013 03:40 PM, Marek Polacek wrote:
On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
wrote:
Ugh. I can see the attraction of your section thing for that case, I
just get the feeling that we should be able to do better some
On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
wrote:
>
> I remember that choosing between 2 and 5 bytes nop in the asm goto was
> tricky: it had something to do with the fact that gcc doesn't know the
> exact size of each instructions until further down within compilation
Oh, you can't do it
On Mon, 2013-08-05 at 12:57 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
> wrote:
> >
> > I remember that choosing between 2 and 5 bytes nop in the asm goto was
> > tricky: it had something to do with the fact that gcc doesn't know the
> > exact size of each in
On 08/05/2013 02:39 PM, Steven Rostedt wrote:
On Mon, 2013-08-05 at 11:20 -0700, Linus Torvalds wrote:
Of course, it would be good to optimize static_key_false() itself -
right now those static key jumps are always five bytes, and while they
get nopped out, it would still be nice if there was s
Здравствуйте!
Хочу предложить Вам целевые переходы интересных для Вашего сайта из,
источником являются email рассылки.
Наши преимущества:
- Возможность таргетинга по любому региону;
- Статистика в личном кабинете нашего сервиса;
- Стоимость перехода гораздо меньше "Яндекс.Директа";
- Размер рек
On 08/05/2013 09:57 AM, Jason Baron wrote:
> On 08/05/2013 03:40 PM, Marek Polacek wrote:
>> On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
>>> On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
>>> wrote:
Ugh. I can see the attraction of your section thing for that case, I
* Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
> wrote:
> >
> > I remember that choosing between 2 and 5 bytes nop in the asm goto was
> > tricky: it had something to do with the fact that gcc doesn't know the
> > exact size of each ins
On 08/05/2013 02:28 PM, Mathieu Desnoyers wrote:
> * Linus Torvalds (torva...@linux-foundation.org) wrote:
>> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
>> wrote:
>>>
>>> I remember that choosing between 2 and 5 bytes nop in the asm goto was
>>> tricky: it had something to do with the fact
On Mon, 2013-08-05 at 17:28 -0400, Mathieu Desnoyers wrote:
> Another thing that bothers me with Steven's approach is that decoding
> jumps generated by the compiler seems fragile IMHO.
The encodings wont change. If they do, then old kernels will not run on
new hardware.
Now if it adds a third o
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Mon, 2013-08-05 at 17:28 -0400, Mathieu Desnoyers wrote:
>
[...]
> > My though is that the code above does not cover all jump encodings that
> > can be generated by past, current and future x86 assemblers.
> >
> > Another way around this issue mi
On 08/05/2013 04:35 PM, Richard Henderson wrote:
On 08/05/2013 09:57 AM, Jason Baron wrote:
On 08/05/2013 03:40 PM, Marek Polacek wrote:
On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
wrote:
Ugh. I can see the attraction of you
On Mon, 2013-08-05 at 22:26 -0400, Jason Baron wrote:
> I think if the 'cold' attribute on the default disabled static_key
> branch moved the text completely out-of-line, it would satisfy your
> requirement here?
>
> If you like this approach, perhaps we can make something like this work
> wit
* H. Peter Anvin (h...@linux.intel.com) wrote:
> On 08/05/2013 02:28 PM, Mathieu Desnoyers wrote:
> > * Linus Torvalds (torva...@linux-foundation.org) wrote:
> >> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
> >> wrote:
> >>>
> >>> I remember that choosing between 2 and 5 bytes nop in the as
On 08/05/2013 09:14 PM, Mathieu Desnoyers wrote:
>>
>> For unconditional jmp that should be pretty safe barring any fundamental
>> changes to the instruction set, in which case we can enable it as
>> needed, but for extra robustness it probably should skip prefix bytes.
>
> On x86-32, some prefixe
Hi,
I'm having trouble building or linking C++ code. Could one of you brains take a
peek at the enclosed and let me know where I'm goofing please?
Regards, and thanks,
George...
gcc --version
gcc (GCC) 4.9.0 20130805 (experimental)
[ 88%] Building CXX object src/CMakeFiles/k
On Mon, Aug 05, 2013 at 10:05:22PM -0700, George R Goffe wrote:
> Hi,
>
> I'm having trouble building or linking C++ code. Could one of you brains take
> a peek at the enclosed and let me know where I'm goofing please?
This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which
51 matches
Mail list logo
