Architecture instruction utilization rates
Hello all, I'm just curious about this, but what is the percentage of (and what are the) unused instructions for each supported architecture under GCC?
Re: Architecture instruction utilization rates
On Mon, Apr 13, 2020 at 8:34 AM Bryce Cherry via Gcc wrote: > Hello all, > > I'm just curious about this, but what is the percentage of (and what are > the) unused instructions for each supported architecture under GCC? > I would bet that this info doesn't exist. And you would have to clarify user vs supervisor instructions. GCC doesn't generate any supervisor instructions. My guess is that on a very simple RISC CPU, the percentage of user mode instructions used is pretty high simply because there are not that many instructions. But the more complicated CISC architectures with lots of instructions are going to be lower because someone would have had to write a pattern specifically to use a special instruction. Maybe someone with broad architecture experience can comment on which simple architecture has the most used. Intuition says a CISC architecture like the x86, m68k, or VAX has the most unused instructions but those have had a lot of work so we might be surprised. Interesting question but it would take a large survey and the number of instructions per cpu model within an architecture will vary. A productive alternative for GCC developers is the question "which instructions on which architectures would it be nice if GCC could take advantage of but currently doesn't?" This one might get an answer. --joel RTEMS
Re: Modifying RTL cost model to know about long-latency loads
On Sat, Apr 11, 2020 at 4:28 PM Sasha Krassovsky via Gcc wrote: > I’m currently modifying the RISC-V backend for a manycore processor where > each core is connected over a network. Each core has a local scratchpad > memory, but can also read and write other cores’ scratchpads. I’d like to add > an attribute to give a hint to the optimizer about which loads will be remote > and therefore longer latency than others. GCC has support for the proposed named address space extension to the ISO C standard. You may be able to use this instead of defining your own attributes. I don't know if this helps with the rtx cost calculation though. This is mostly about support for more than one address space. See "Named Address Spaces" in the gcc internals docs, and the *_ADDR_SPACE_* stuff in the sources. The problem may be one similar to what Alan Modra mentioned. I would suggest stepping through the cost calculation code in a debugger to see what is happening. Jim
Re: Not usable email content encoding
On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote: >On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote: >>On Wed, 8 Apr 2020, Mark Wielaard wrote: >>>Earlier versions of Mainman2 had some issues which might accidentally >>>change some headers. But the latest fixes make this possible. It is >>>how the FSF handles DMARC for various GNU mailinglists (by NOT >>>modifying the headers and body and passing through the DKIM >>>signatures): >>>https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html >> >>Oh, that would be nice to have at sourceware.org. Please? :-) > >Yes, please please please, can we have this? In case it isn't obvious, we are already running the latest available version of mailman 2.
Martin Liska appointed GCC IPA Reviewer
I am pleased to announce that the GCC Steering Committee has appointed Martin Liska as IPA Reviewer. Please join me in congratulating Martin on his new role. Martin, please update your listing in the MAINTAINERS file. Happy hacking! David
Martin Jambor appointed GCC IPA Reviewer
I am pleased to announce that the GCC Steering Committee has appointed Martin Jambor as GCC IPA Reviewer. Please join me in congratulating Martin on his new role. Martin, please update your listing in the MAINTAINERS file. Happy hacking! David
Re: Not usable email content encoding
Hello, On Mon, 13 Apr 2020, Christopher Faylor wrote: > On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote: > >On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote: > >>On Wed, 8 Apr 2020, Mark Wielaard wrote: > >>>Earlier versions of Mainman2 had some issues which might accidentally > >>>change some headers. But the latest fixes make this possible. It is > >>>how the FSF handles DMARC for various GNU mailinglists (by NOT > >>>modifying the headers and body and passing through the DKIM > >>>signatures): > >>>https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html > >> > >>Oh, that would be nice to have at sourceware.org. Please? :-) > > > >Yes, please please please, can we have this? > > In case it isn't obvious, we are already running the latest available > version of mailman 2. I think that means that dmarc_moderation_action: "Munge From" can simply be switched off then (at least I don't see which other headers e.g. gcc@ is rewriting that would cause DMARC to scream; and if there are any, then it would be better to disable those as well. Same with any potential body rewriting that might still happen). I would offer help testing that this doesn't cause delivery issues, e.g. on some test email list, but it seems none of my domains is DMARC-infected :-/ Ciao, Michael. P.S: I wonder btw. why the From munging is enabled also for p=none domains like redhat.com. The RFC says this is to be used for gathering DMARC feedback, not requiring any specific action for the mail text itself on the sender or receiver. But an answer to this would be moot with the above non-munging of From.
