Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs
From: Peter Zijlstra
Date: Sat Jun 29 2019 - 03:10:51 EST
On Fri, Jun 28, 2019 at 11:44:16AM -0700, Nick Desaulniers wrote:
> On Fri, Jun 28, 2019 at 6:31 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > For those with interest; full patches at:
> >
> > https://lkml.kernel.org/r/20190628102113.360432762@xxxxxxxxxxxxx
>
> Do you have a branch pushed that I can pull this from to quickly test w/ Clang?
I've not yet pushied it out, will do on Monday or so.
> The .skip trick is wild; I don't quite understand the negation in the
> above or patch 8/8 for is_byte/is_long.
Yes, that's a bit magic. What happens is that GAS has:
false := 0
true := ~false
(it lacks a boolean not and uses a bitwise negate instead). Therefore,
the result of an (true) compare is all-1-s (or -1), and since we want a
single .skip we have to negate.
The actual condition for the result is more complicated than it should
be, but that only came to me after sendind out these patches, basically
it should be:
(val >> 31) == (val >> 7)
to test if a s32 van be represented in a s8.
> For the wrong __jump_table entry; I consider that a critical issue we
> need to fix before the clang-9 release. I'm unloading my current
> responsibilities at work to be able to sit and focus on bug. I'll
> probably start a new thread with you, tglx, Josh, and our mailing list
> next week (sorry for co-opting this thread). I have been using
> creduce quite successfully for finding and fixing our previous codegen
> bugs (https://nickdesaulniers.github.io/blog/2019/01/18/finding-compiler-bugs-with-c-reduce/),
> but I need to sit and understand the precise failure more in order to
> reduce the input. We can see pretty well where in the compilation
> pipeline things go wrong; I just find it hard to page through large
> inputs such as whole translation units.
Sure; add me to the thread and I'll be glad to answer anything I can.