Re: Builtin for consulting value analysis (better ffs() code gen)

[Florian Weimer via Gcc]

* Andrew Cooper via Gcc:

> Anyway - is there a way of doing this that I've managed to overlook?

Use __builtin_ffs?

I think there's some concern for GCC that some of the alternative x86-64
implementations do not follow the AMD and Intel behavior.

Thanks,
Florian

Re: Builtin for consulting value analysis (better ffs() code gen)

[Andrew Cooper via Gcc]

On 14/03/2024 6:04 am, Alexander Monakov wrote:
> On Thu, 14 Mar 2024, Andrew Cooper via Gcc wrote:
>
>> I suppose that what I'm looking for is something a little like
>> __builtin_constant_p() which can either be used in a straight if(), or
>> in a __builtin_choose_expr().
>>
>> Anyway - is there a way of doing this that I've managed to overlook?
> I am missing what is lacking for you with __builtin_constant_p, I would
> do it like this:
>
> unsigned ffs(unsigned x)
> {
> unsigned res;
> unsigned nonzero = x != 0;
> if (__builtin_constant_p(nonzero) && nonzero)
> asm("bsf %1, %0" : "=r"(res) : "rm"(x));
> else {
> res = -1;
> asm("bsf %1, %0" : "+r"(res) : "rm"(x));
> }
> return res;
> }

Oh - so it does.  I'd not considered that expressing it like that would
still work.

>
> or with handling known-zero-input case like this:
>
> unsigned ffs(unsigned x)
> {
> unsigned res;
> unsigned nonzero = x != 0;
> if (!__builtin_constant_p(nonzero)) {
> res = -1;
> asm("bsf %1, %0" : "+r"(res) : "rm"(x));
> } else if (nonzero) {
> asm("bsf %1, %0" : "=r"(res) : "rm"(x));
> } else {
> res = -1;
> }
> return res;
> }
>
>
> Does it work for you?

I simplified things when asking the question.  The real implementation
has a general

    if (__builtin_constant_p(x))
        return __builtin_ffs(x);

so any known-constant value can be folded.  What I'm dealing with is the
remainder of the cases.

Anyway - thankyou for your help.

~Andrew

Re: Builtin for consulting value analysis (better ffs() code gen)

[Andrew Cooper via Gcc]

On 14/03/2024 11:02 am, Florian Weimer wrote:
> * Andrew Cooper via Gcc:
>
>> Anyway - is there a way of doing this that I've managed to overlook?
> Use __builtin_ffs?
>
> I think there's some concern for GCC that some of the alternative x86-64
> implementations do not follow the AMD and Intel behavior.

This is why I'm not asking "please improve the code gen of
__builtin_ffs()".  Its a can of worms I don't expect anyone wants to open.

But in the case that I can do better owing to a narrower scope, I'd like
to do so.

~Andrew

Re: Builtin for consulting value analysis (better ffs() code gen)

[Andreas Schwab via Gcc]

On Mär 14 2024, Andrew Cooper via Gcc wrote:

> so any known-constant value can be folded.  What I'm dealing with is the
> remainder of the cases.

Which cases remain?

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Using std types and functions within GCC

[Pierrick Philippe]

Hi all,

I was wondering, is there any conventions or guidelines regarding the
usage of types and/or functions coming from the C++ std library within
the compiler?

To explicit a bit more, I am working on modification on the analyzer and
might need to use a pair.

Thank you for your time,

Pierrick

Re: Using std types and functions within GCC

[Jonathan Wakely via Gcc]

On Thu, 14 Mar 2024 at 12:54, Pierrick Philippe
 wrote:
>
> Hi all,
>
> I was wondering, is there any conventions or guidelines regarding the
> usage of types and/or functions coming from the C++ std library within
> the compiler?

The relevant header needs to be included from the gcc/system.h header.
Look in there for INCLUDE_STRING, INCLUDE_VECTOR etc. and how those
macros are used in other sources.

> To explicit a bit more, I am working on modification on the analyzer and
> might need to use a pair.

A grep of the source shows that  is already included in
gcc/system.h and std::pair is already used in several places.

Re: Using std types and functions within GCC

[David Malcolm via Gcc]

On Thu, 2024-03-14 at 13:28 +, Jonathan Wakely via Gcc wrote:
> On Thu, 14 Mar 2024 at 12:54, Pierrick Philippe
>  wrote:
> > 
> > Hi all,

Hi Pierrick!  It was good to meet you at FOSDEM.

> > 
> > I was wondering, is there any conventions or guidelines regarding
> > the
> > usage of types and/or functions coming from the C++ std library
> > within
> > the compiler?
> 
> The relevant header needs to be included from the gcc/system.h
> header.
> Look in there for INCLUDE_STRING, INCLUDE_VECTOR etc. and how those
> macros are used in other sources.
> 
> > To explicit a bit more, I am working on modification on the
> > analyzer and
> > might need to use a pair.
> 
> A grep of the source shows that  is already included in
> gcc/system.h and std::pair is already used in several places.

Thanks Jonathan.

A couple of other things to note:

- bear in mind that we need to be somewhat conservative in our usage of
C++ internally: our code needs to be C++11, compilable by GCC 4.8.3,
and parsable by gengtype and by xgettext.  For example, there's at
least one place where I'd have used std::optional, but that's C++14 and
so unavailable.

- some parts of our code manage memory using our custom garbage
collector (via GTY and gengtype), and other parts use C++11 move
semantics.  I suspect that these two approaches to memory management
aren't especially compatible with each other.  For example, our vec
class works with the GC but not (I think) with move, whereas
std::vector works with C++11.  We make the simplifying assumption
within the analyzer that the garbage collector will never run within
the analysis pass, and the analyzer makes use of move semantics, ctors,
dtors, etc.

Feel free to use std::pair in the analyzer.

Hope this is helpful
Dave

Re: Using std types and functions within GCC

[Jonathan Wakely via Gcc]

On Thu, 14 Mar 2024 at 14:49, David Malcolm  wrote:
>
> On Thu, 2024-03-14 at 13:28 +, Jonathan Wakely via Gcc wrote:
> > On Thu, 14 Mar 2024 at 12:54, Pierrick Philippe
> >  wrote:
> > >
> > > Hi all,
>
> Hi Pierrick!  It was good to meet you at FOSDEM.
>
> > >
> > > I was wondering, is there any conventions or guidelines regarding
> > > the
> > > usage of types and/or functions coming from the C++ std library
> > > within
> > > the compiler?
> >
> > The relevant header needs to be included from the gcc/system.h
> > header.
> > Look in there for INCLUDE_STRING, INCLUDE_VECTOR etc. and how those
> > macros are used in other sources.
> >
> > > To explicit a bit more, I am working on modification on the
> > > analyzer and
> > > might need to use a pair.
> >
> > A grep of the source shows that  is already included in
> > gcc/system.h and std::pair is already used in several places.
>
> Thanks Jonathan.
>
> A couple of other things to note:
>
> - bear in mind that we need to be somewhat conservative in our usage of
> C++ internally: our code needs to be C++11, compilable by GCC 4.8.3,
> and parsable by gengtype and by xgettext.  For example, there's at
> least one place where I'd have used std::optional, but that's C++14 and
> so unavailable.

C++17, so even more unavailable!

> - some parts of our code manage memory using our custom garbage
> collector (via GTY and gengtype), and other parts use C++11 move
> semantics.  I suspect that these two approaches to memory management
> aren't especially compatible with each other.  For example, our vec
> class works with the GC but not (I think) with move, whereas
> std::vector works with C++11.  We make the simplifying assumption
> within the analyzer that the garbage collector will never run within
> the analysis pass, and the analyzer makes use of move semantics, ctors,
> dtors, etc.
>
> Feel free to use std::pair in the analyzer.
>
> Hope this is helpful
> Dave
>

Re: Builtin for consulting value analysis (better ffs() code gen)

[Andrew Cooper via Gcc]

On 14/03/2024 12:03 pm, Andreas Schwab wrote:
> On Mär 14 2024, Andrew Cooper via Gcc wrote:
>
>> so any known-constant value can be folded.  What I'm dealing with is the
>> remainder of the cases.
> Which cases remain?

None, thanks to the answers on this thread.

The overall structure I've got now is:

unsigned int ffs(unsigned int x)
{
    if ( __builtin_constant_p(x) )
        return __builtin_ffs(x);  // Allows constant folding

#ifndef arch_ffs
#define arch_ffs __builtin_ffs
#endif

    return arch_ffs(x);
}

And for x86's arch_ffs(),

unsigned int arch_ffs(unsigned int x)
{
    unsigned int res;

    if ( __builtin_constant_p(x > 0) && x > 0 )
    {
        // Well defined when x is known non-zero
        asm("bsf %1, %0" : "=r"(res) : "rm"(x));
    }
    else
    {
        // The architects say this is safe even for 0.
        res = -1;
    asm("bsf %1, %0" : "+r"(res) : "rm"(x));
    }

    return res + 1;
}


This gives the same code gen as before (give or take some register
shuffling), without having to rely on the programmer to remember to get
their ffs()'s separated from their __ffs()'s as it pertains to undefined
input.

The other architectures which have better-defined instructions don't
need any of these games to retain the same good code-gen that is
currently expressed with a maze of subtly-different functions.

~Andrew

Re: [RFC] add regenerate Makefile target

[Simon Marchi via Gcc]

On 2024-03-13 04:02, Christophe Lyon via Gdb wrote:
> Hi!
> 
> After recent discussions on IRC and on the lists about maintainer-mode
> and various problems with auto-generated source files, I've written
> this small prototype.
> 
> Based on those discussions, I assumed that people generally want to
> update autotools files using a script similar to autoregen.py, which
> takes care of running aclocal, autoheader, automake and autoconf as
> appropriate.
> 
> What is currently missing is a "simple" way of regenerating other
> files, which happens normally with --enable-maintainer-mode (which is
> reportedly broken).  This patch as a "regenerate" Makefile target
> which can be called to update those files, provided
> --enable-maintainer-mode is used.
> 
> I tried this approach with the following workflow for binutils/gdb:
> - run autoregen.py in srcdir
> - cd builddir
> - configure --enable-maintainer-mode 
> - make all-bfd all-libiberty regenerate -j1
> - for gdb: make all -C gdb/data-directory -j1
> - make all -jXXX
> 
> Making 'all' in bfd and libiberty is needed by some XXX-gen host
> programs in opcodes.
> 
> The advantage (for instance for CI) is that we can regenerate files at
> -j1, thus avoiding the existing race conditions, and build the rest
> with -j XXX.
> 
> Among drawbacks:
> - most sub-components use Makefile.am, but gdb does not: this may make
>   maintenance more complex (different rules for different projects)
> - maintaining such ad-hoc "regenerate" rules would require special
>   attention from maintainers/reviewers
> - dependency on -all-bfd and all-libiberty is probably not fully
>intuitive, but should not be a problem if the "regenerate" rules
>are used after a full build for instance
> 
> Of course Makefile.def/Makefile.tpl would need further cleanup as I
> didn't try to take gcc into account is this patch.
> 
> Thoughts?

My first thought it: why is it a Makefile target, instead of some script
on the side (like autoregen.sh).  It would be nice / useful to be
able to it without configuring / building anything.  For instance, the
autoregen buildbot job could run it without configuring anything.
Ideally, the buildbot wouldn't maintain its own autoregen.py file on the
side, it would just use whatever is in the repo.

Looking at the rule to re-generate copying.c in gdb for instance:

# Make copying.c from COPYING
$(srcdir)/copying.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/../COPYING3 
$(srcdir)/copying.awk
   awk -f $(srcdir)/copying.awk \
   < $(srcdir)/../COPYING3 > $(srcdir)/copying.tmp
   mv $(srcdir)/copying.tmp $(srcdir)/copying.c

There is nothing in this code that requires having configured the source
tree.  This code could for instance be moved to some
generate-copying-c.sh script.  generate-copying-c.sh could be called by
an hypothetical autoregen.sh script, as well as the copying.c Makefile
target, if we want to continue supporting the maintainer mode.

Much like your regenerate targets, an autoregen.sh script in a given
directory would be responsible to re-generate all the files in this
directory that are generated and checked in git.  It would also be
responsible to call any autoregen.sh file in subdirectories.

There's just the issue of files that are generated using tools that are
compiled.  When experimenting with maintainer mode the other day, I
stumbled on the opcodes/i386-gen, for instance.  I don't have a good
solution to that, except to rewrite these tools in a scripting language
like Python.

Simon

Re: GSoC

[Thomas Schwinge]

Hi Abhinav!

Thanks for your interest in contributing to GCC, and thanks to Martin for
all the information you already provided.  Just a bit more, to get you
started on developing a proper project proposal:

On 2024-03-13T14:54:52+0100, Martin Jambor  wrote:
> On Tue, Mar 12 2024, Abhinav Gupta wrote:
>> I looked at all the links you provided in the reply and read the
>> paper cited on the GCC page for GSoC. I also looked into the rust
>> frontend project during this time, and the Offloading project
>> interests me more, so I will focus solely on it in the remaining seven
>> days before the deadline for GSoC application submission.
>
> AFAIU, in five days (from now) the application period *opens*, the
> deadline is 2nd April.  Still it is good idea not to lose any time.

Indeed, no rush yet.  :-)

>> Are there other resources I can look at to better understand the whole
>> process?

At some point, no too late, you should spend some time on learning how to
build GCC, and run the test suite.
 and
 have
some pointers to get started.  If you have specific questions, we're
happy to help, of course.

>> Reading the git commit on the website is proving to be very
>> slow.

Yes, that's not going to be necessary.

>> I think the git commit about Intel MIC would be like a
>> "template" in loose terms

Right, that's in fact a very good description.  The idea here is not to
bring back the whole Intel MIC emulator, but something very much simpler.

>> to implement the host-ISA mode at least, but
>> for the libgomp plugin, I need a better understanding.

Find existing libgomp plugins as 'libgomp/plugin/plugin-*.c'.  The
'GOMP_OFFLOAD_[...]' functions implement the entry points, the offloading
plugin API.  Actually also the very simple 'libgomp/oacc-host.c' should
be helpful.  That's essentially the API you need to care about (for
OpenACC; but OpenMP 'target' also won't require much more, for a start).

Make some thoughts (or actual experiments) about how we could
use/implement a separate host process for code offloading.

And otherwise, as Martin said:

> You need to understand how OpenMP programs are internally represented.
>
> Look at the following (hopefully correct, at least as long as you try it
> on a system without any Offloading enabled) simple testcase for OpenMP
> target construct:
>
> --
> #include 
>
> volatile int v = 1;
>
> int main (int argc, char **argv)
> {
>   int i = v;
>
> #pragma omp target map(to:i)
>   {
> printf ("OpenMP target hello world, i is: %i\n", i);
>   }
>
>   return 0;
> }
> --
>
> and compile it with:
>
>   gcc -fopenmp omptgt-hello.c -O2 -fdump-tree-optimized
>
> and then look at the generated optimized dump.  This should give you an
> idea how OpenMP regions are internally represented (as outlined
> functions) and how calls into libgomp, the run-time library doing a lot
> of the magic, look like.
>
> You can try to do more similar exercises with more OpenMP testcase which
> you can find in sub-directory libgomp/testsuite/libgomp.c of in the GCC
> repository.
>
> And then you should perhaps have a look into libgomp itself (you'll find
> it in libgomp sub-directory) how GOMP_target_ext is implemented - though
> don't worry if you don't understand many of the details, it is complex
> stuff.  At this point hopefully more of the contents of the Offloading
> wiki page will make sense.
>
> Again, ask on the mailing list if you have any specific questions.


Grüße
 Thomas


>> On Thu, 7 Mar 2024 at 20:37, Martin Jambor  wrote:
>>>
>>> Hello,
>>>
>>> On Wed, Mar 06 2024, Abhinav Gupta via Gcc wrote:
>>> > Dear GCC Community,
>>> > I hope this email finds you well. My name is Abhinav Gupta. I am a
>>> > 3rd-year student at IIT Tirupati pursuing a bachelor's degree in
>>> > computer science and engineering. I am writing to express my interest
>>> > in contributing to the GCC project under GSoC.
>>>
>>> We are very happy that you find contributing to GCC interesting.
>>>
>>> > I am interested in two projects - Offloading to a separate process on
>>> > the same host, I am already working in parallel computing,
>>> > specifically parallelising tensor algorithms using various techniques
>>> > as part of my research project at IIT Tirupati. Although this is not
>>> > directly related to compilers, I will be able to get going with the
>>> > project quickly.
>>>
>>> I'd personally very much like to see this project implemented.  There is
>>> a lot of information on offloading at
>>> https://gcc.gnu.org/wiki/Offloading
>>>
>>> To give you a bit more context where the idea comes from, it was first
>>> thought of in email thread starting with
>>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603984.html and
>>> the patch that was "scrubbed" from the

gcc-11-20240314 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20240314 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20240314/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 5cc46561670ffc7f07004e6b28ed24ab94379ec9

You'll find:

 gcc-11-20240314.tar.xz   Complete GCC

  SHA256=acefa440d26b2e3e768ddbe1848a000a09e4f60d6948260f52db470763d3cb75
  SHA1=12347e8ba784f5c2ad3b93a11067e2eb22cf4637

Diffs from 11-20240307 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

RELLEB relocation format for ELF

[Fangrui Song via Gcc]

The relocation formats REL and RELA for ELF are inefficient. In a
release build of Clang for x86-64, .rela.* sections consume a
significant portion (approximately 20.9%) of the file size.

I propose RELLEB, a new format offering significant file size
reductions: 17.2% (x86-64), 16.5% (aarch64), and even 32.4% (riscv64)!

Your thoughts on RELLEB are welcome!

Detailed analysis:
https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf
generic ABI (ELF specification):
https://groups.google.com/g/generic-abi/c/yb0rjw56ORw
binutils feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=31475
LLVM: 
https://discourse.llvm.org/t/rfc-relleb-a-compact-relocation-format-for-elf/77600

Implementation primarily involves binutils changes. Any volunteers?
For GCC, a driver option like -mrelleb in my Clang prototype would be
needed. The option instructs the assembler to use RELLEB.