Re: typeof and operands in named address spaces

Re: typeof and operands in named address spaces

[Peter Zijlstra]

+ 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. We recently had
a _lot_ of 'fun' trying to strip volatile from a type, see here:

  https://lore.kernel.org/lkml/875zimp0ay.fsf@mpe.ellerman.id.au

which resulted in the current __unqual_scalar_typeof() hack.

If we're going to do compiler extentions here, can we pretty please have
a sane means of modifying qualifiers in general?

Re: typeof and operands in named address spaces

[Segher Boessenkool]

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.

> We recently had
> a _lot_ of 'fun' trying to strip volatile from a type, see here:
> 
>   https://lore.kernel.org/lkml/875zimp0ay.fsf@mpe.ellerman.id.au
> 
> which resulted in the current __unqual_scalar_typeof() hack.
> 
> If we're going to do compiler extentions here, can we pretty please have
> a sane means of modifying qualifiers in general?

What do you want to do with it?  It may be more feasible to do a
compiler extension for *that*.


Segher

Re: typeof and operands in named address spaces

[Nick Desaulniers]

On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
<segher@kernel.crashing.org> 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

[Peter Zijlstra]

On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
> <segher@kernel.crashing.org> 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.

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.

Re: typeof and operands in named address spaces

[Nick Desaulniers]

On Mon, Nov 9, 2020 at 11:57 PM Peter Zijlstra <peterz@infradead.org> 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

Re: typeof and operands in named address spaces

[Peter Zijlstra]

On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:

> 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?

Right, x86 Named Address Space:

  https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Named-Address-Spaces.html#Named-Address-Spaces

Also, Google found me this:

  https://reviews.llvm.org/D64676

The basic problem seems to be they act exactly like qualifiers in that
typeof() preserves them, so if you have:

( and now I realize the parent isn't Cc'd to LKML, find here:
  https://gcc.gnu.org/pipermail/gcc/2020-November/234119.html )

> --cut here--
> #define foo(_var)                    \
> ({                            \
> typeof(_var) tmp__;                    \
> asm ("mov %1, %0" : "=r"(tmp__) : "m"(_var));    \
> tmp__;                        \
> })
>
> __seg_fs int x;
>
> int test (void)
> {
> int y;
>
> y = foo (x);
> return y;
> }
> --cut here--

> when compiled with -O2 for x86 target, the compiler reports:
>
> pcpu.c: In function ‘test’:
> pcpu.c:14:3: error: ‘__seg_fs’ specified for auto variable ‘tmp__’


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

So far that seems sufficient. Although the Devil's advocate in me is
trying to construct a case where we need to preserve const but strip
volatile and that's then means we need to detect if the original has
const or not, because unconditionally adding it will be wrong.

Re: typeof and operands in named address spaces

[Segher Boessenkool]

On Tue, Nov 10, 2020 at 09:11:08PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:
> > 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?
> 
> Right, x86 Named Address Space:
> 
>   https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Named-Address-Spaces.html#Named-Address-Spaces
> 
> Also, Google found me this:
> 
>   https://reviews.llvm.org/D64676
> 
> The basic problem seems to be they act exactly like qualifiers in that
> typeof() preserves them, so if you have:

GCC has the four standard type qualifiers (const, volatile, restrict,
and _Atomic), but also the address space things yes.

> > Maybe stripping all qualifiers is fine since you can add them back in
> > if necessary?
> 
> So far that seems sufficient. Although the Devil's advocate in me is
> trying to construct a case where we need to preserve const but strip
> volatile and that's then means we need to detect if the original has
> const or not, because unconditionally adding it will be wrong.

If you want to drop all qualifiers, you only need a way to convert
something to an rvalue (which always has an unqualified type).  So maybe
make syntax for just *that*?  __builtin_unqualified() perhaps?  Which
could be useful in more places than just doing an unqualified_typeof.


Segher

Re: typeof and operands in named address spaces

[Uros Bizjak]

On Tue, Nov 10, 2020 at 7:43 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Mon, Nov 9, 2020 at 11:57 PM Peter Zijlstra <peterz@infradead.org> 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.

GCC 14+ and clang 19+ provide __typeof_unqual__() [1] operator in all
c modes. Linux kernel 6.15 provides the USE_TYPEOF_UNQUAL macro that
can be used to check availability of __typeof_unqual__().

[1] https://en.cppreference.com/w/c/keyword/typeof_unqual

Uros.

> 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

Re: typeof and operands in named address spaces

[Segher Boessenkool]

On Tue, Nov 10, 2020 at 08:57:42AM +0100, Peter Zijlstra wrote:
> On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> > On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > > > 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.
> 
> 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
> ;-)

My point is that removing most qualifiers usually is a problem, so
before doing this, we should think if it is such a good plan, whether
there is a safer / saner solution, etc.


Segher

Re: typeof and operands in named address spaces

[Peter Zijlstra]

On Mon, Nov 09, 2020 at 01:38:51PM -0600, 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.
> 
> > We recently had
> > a _lot_ of 'fun' trying to strip volatile from a type, see here:
> > 
> >   https://lore.kernel.org/lkml/875zimp0ay.fsf@mpe.ellerman.id.au
> > 
> > which resulted in the current __unqual_scalar_typeof() hack.
> > 
> > If we're going to do compiler extentions here, can we pretty please have
> > a sane means of modifying qualifiers in general?
> 
> What do you want to do with it?  It may be more feasible to do a
> compiler extension for *that*.

Like with the parent use-case it's pretty much always declaring
temporaries in macros. We don't want the temporaries to be volatile, or
as the parent post points out, to have a segment qualifier.