kernel+toolchain tracks at plumbers

[Nick Desaulniers via Gcc]

Hi All,
Between the GNU toolchain track, GNU toolchain MC, LLVM BoF, and LLVM
MC at Plumbers 2020, we may be getting close to having more toolchain
topics than kernel topics at plumbers this year. :^D
https://linuxplumbersconf.org/event/7/timetable/?view=lpc

I'll be spending time between the above 4 for most of the conference.
I wanted to share the word on some of the talks we had lined up that
would be useful to have folks from a bunch of different tooling
backgrounds to help inform the discussion.  In particular:

Dependency Ordering in the Linux kernel
https://linuxplumbersconf.org/event/7/contributions/821/
which should have feedback on the Linux kernel's memory model for implementers.

and

asm goto w/ outputs
https://linuxplumbersconf.org/event/7/contributions/801/
which would be useful to help discuss collaboration on designs of
future language extension in the context of the Linux kernel.

I'm particularly interested in
https://linuxplumbersconf.org/event/7/contributions/771/ ("Exploring
Profile Guided Optimization of the Linux Kernel") and the BoF
https://linuxplumbersconf.org/event/7/contributions/726/.  If there's
other topics that would be particularly helpful to have LLVM folks in
the room, please let me know and I'll help promote it.

See you at the show!
-- 
Thanks,
~Nick Desaulniers

Re: typeof and operands in named address spaces

[Nick Desaulniers via Gcc]

On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
 wrote:
>
> On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> >
> > + lots of people and linux-toolchains
> >
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > Hello!
> > >
> > > I was looking at the recent linux patch series [1] where segment
> > > qualifiers (named address spaces) were introduced to handle percpu
> > > variables. In the patch [2], the author mentions that:
> > >
> > > --q--
> > > Unfortunately, gcc does not provide a way to remove segment
> > > qualifiers, which is needed to use typeof() to create local instances
> > > of the per-cpu variable. For this reason, do not use the segment
> > > qualifier for per-cpu variables, and do casting using the segment
> > > qualifier instead.
> > > --/q--
> >
> > C in general does not provide means to strip qualifiers.
>
> Most ways you can try to use the result are undefined behaviour, even.

Yes, removing `const` from a `const` declared variable (via cast) then
expecting to use the result is a great way to have clang omit the use
from the final program.  This has bitten us in the past getting MIPS
support up and running, and one of the MTK gfx drivers.
-- 
Thanks,
~Nick Desaulniers

Re: typeof and operands in named address spaces

[Nick Desaulniers via Gcc]

On Mon, Nov 9, 2020 at 11:57 PM Peter Zijlstra  wrote:
>
> Stripping const to delcare another variable is useful though. Sure C has
> sharp edges, esp. if you cast stuff, but since when did that stop anyone
> ;-)
>
> The point is, C++ has these very nice template helpers that can strip
> qualifiers, I want that too, for much of the same reasons. We might not
> have templates :-(, but we've become very creative with our
> pre-processor.
>
> Surely our __unqual_scalar_typeof() cries for a better solution.

Yeah, and those macros bloat the hell out of our compile times, for
both compilers.  I think it's reasonable to provide variants of
typeof() that strip qualifiers.

Some questions to flesh out more of a design.

Would we want such a feature to strip all qualifiers or just specific
individual ones? The more specific variants could be composed, ie.

nonconst_typeof(x) y = x + 1;
nonvol_typeof(z) w = z + 1;
#define nonqual_typeof(v) nonconst_typeof(nonvol_typeof(v))
nonqual_typeof(v) k = v + 1;
vs just:
nonqual_typeof(v) k = v + 1;

When I think of qualifiers, I think of const and volatile.  I'm not
sure why the first post I'm cc'ed on talks about "segment" qualifiers.
Maybe it's in reference to a variable attribute that the kernel
defines?  Looking at Clang's Qualifier class, I see const, volatile,
restrict (ah, right), some Objective-C stuff, and address space
(TR18037 is referenced, I haven't looked up what that is) though maybe
"segment" pseudo qualifiers the kernel defines expand to address space
variable attributes?

Maybe stripping all qualifiers is fine since you can add them back in
if necessary?

const volatile foo;
const nonqual_typeof(foo) bar = foo; // strips off both qualifiers,
re-adds const to bar
-- 
Thanks,
~Nick Desaulniers