GCC 7.4 Release Candidate available from gcc.gnu.org
A release candidate for GCC 7.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/7.4.0-RC-20181129/ and shortly its mirrors. It has been generated from SVN revision 266611. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release GCC 7.4 at the end of next week.
Re: PROPOSAL: Extend inline asm syntax with size spec
On Thu, Nov 29, 2018 at 08:46:34PM +0900, Masahiro Yamada wrote: > But, I'd like to ask if x86 people want to keep this macros.s approach. > Revert 77b0bf55bc675 right now > assuming the compiler will eventually solve the issue? Yap, considering how elegant the compiler solution is and how much problems this macros-in-asm thing causes, I think we should patch out the latter and wait for gcc9. I mean, the savings are not so mind-blowing to have to deal with the fallout. But this is just my opinion. Thx. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: Question about make_extraction() in combine.c
On 11/21/18 9:33 AM, Segher Boessenkool wrote: > On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote: >> The internal RTL should not be dictating what the target arch can or >> cannot implement. Reload should insert any needed conversions, >> especially ones which narrow the size. > > Well, that depends. A zero_extract of mem is only defined for byte_mode, > just like SET is only defined for VOIDmode (on the SET itself, not its > args). Because this is guaranteed, nothing in GCC ever needs to check > this. That is the theory of course; in reality quite a few targets have > used other modes for the mem in a zero_extract, and this seems to have > mostly worked. Right. > > As another example, closer by, an extract length of 0 is not allowed > either, for zero_extract. And this *did* cause problems recently. Very true. I don't doubt there's still corner cases that haven't been well documented. > > Why was it documented as requiring byte mode? Was this changed, just > the documentation was not updated? I don't think it was ever documented why byte mode was required, merely that it was required. I can recall stumbling over it in the early/mid 90s. I've got references to the byte requirement going back to early 1992 in my archives. After some wandering of those archives, folks were clearly worried about the extv/insv insns reading/writing beyond the boundary of the current object. If you restrict memory ops to QImode, then you resolve that problem. But we're unlikely to get a definitive answer here. I think the real question is can we reasonably lift the restriction. Jeff
Re: question about attribute aligned for functions
On 11/28/18 9:07 PM, Jeff Law wrote:
On 11/27/18 11:57 AM, Martin Sebor wrote:
On 11/26/18 3:37 PM, Jeff Law wrote:
On 11/23/18 12:31 PM, Martin Sebor wrote:
GCC currently accepts the declaration of f0 below but ignores
the attribute. On aarch64 (and I presume on other targets with
a default function alignment greater than 1), GCC rejects f1
with an error, even though it accepts -falign-functions=1
without as much as a warning.
Clang, on the other hand, rejects f0 with a hard error because
the alignment is not a power of two, but accepts f1 and appears
to honor the attribute. It also accepts -falign-functions=1.
I think diagnosing f0 with a warning is helpful because an explicit
zero alignment is most likely a mistake (especially when it comes
from a macro or some computation).
But I don't see a good reason to reject a program that specifies
a smaller alignment for a function when the default (or minimum)
alignment is greater. A smaller alignment is trivially satisfied
by a greater alignment so either accepting it or dropping it seems
preferable to failing with an error (either could be with or without
a warning).
__attribute__ ((aligned (0))) void f0 (void); // accepted, ignored
__attribute__ ((aligned (1))) void f1 (void); // aarch64 error
__attribute__ ((aligned (4))) void f4 (void); // okay
Does anyone know why GCC rejects the program, or can anyone think
of a reason why GCC should not behave as suggested above?
Note we have targets that support single byte opcodes and do not have
any requirements for functions starting on any boundary. mn103 comes to
mind.
However, the attribute can't be used to decrease a function's alignment,
so values of 0 or 1 are in practice totally uninteresting and one could
make an argument to warn for them.
The attribute does reduce the default alignment at least on some
targets. For instance, on x86_64 it lowers it from the default
16 to as little as 2, but it silently ignores 1.
[ ... ]
You cannot use this attribute to decrease the alignment of a function,
only to increase it. However, when you explicitly specify a function
alignment this overrides the effect of the
@option{-falign-functions} (@pxref{Optimize Options}) option for this
function.
[ ... ]
My reading of that would be that I would get an error/warning if I even
specified an alignment attribute which decreased the alignment.
If it instead said something like
You can not rely on this attribute to decrease ...
Then current behavior (where apparently you can decrease the alignment
on some ports) makes much more sense.
I guess it ultimately depends on how one interprets that tidbit from the
docs.
GCC does disallow decreasing the function alignment -- but only
for functions that were already declared with a more restrictive
one. Like this:
__attribute__ ((aligned (4))) void f (void);
__attribute__ ((aligned (2))) void f (void);
warning: ignoring attribute ‘aligned (2)’ because it conflicts with
attribute ‘aligned (4)’
It doesn't warn about going from the default (say 16 on i86)
to something smaller, and it honors that lower alignment up
to the supported minimum. It's probably worth clarifying in
the manual. Let me propose something.
Whether or not to warn in general if the alignment attribute is smaller
than the default may be subject to debate. I guess it depends on the
general intent that we'd find in real world codes.
I would expect real world code to care about achieving at least
the specified alignment.
If we only allow increasing, yes. At which point what do the values 0
or 1 realistically mean?
If we only allowed increasing then both 0 and 1 would be
meaningless.
If we allow decreasing, then the user may be asking for a smaller
alignment to achieve better code density.
Yes, that's definitely possible (I just opened pr88231 -
aligned functions laid down inefficiently, as I noticed this
doesn't work as well as it could and arguably should). But they
can't get it if the target doesn't support it. In which case I
think adding a new warning to point it out might be useful. At
the same time, users wanting maximum density across all their
targets shouldn't have to worry about what the minimum alignment
is on each of them and hardwire different constants into
the attribute. I think they should be able to specify 1 and
have GCC round it up as necessary, with no warning. So I'd make
the new warning off by default.
A less restrictive alignment requirement is satisfied by providing
a more restrictive one, and (the above notwithstanding) the manual
documents that
You cannot use this attribute to decrease the alignment of
a function, only to increase it.
So I wouldn't expect real code to be relying on decreasing
the alignment.
That said, since GCC does make it possible to decrease the default
alignment of functions, I can think of no reason for it not to
continue when it's possible. I.e., on targets with underaligned
instruction read
Re: Gimpel lowering question.
On 11/28/18 14:37, Andrew Pinski wrote:
On Wed, Nov 28, 2018 at 9:47 AM Michael Eager wrote:
On 11/28/18 09:10, Jeff Law wrote:
On 11/28/18 10:00 AM, Michael Eager wrote:
I have a small test case which generates poor quality code on my target.
Here is the original:
if (cond1 == 2048 || cond2 == 8)
{
x = x + y;
}
return x;
This ends up generating a series of instructions to compute a flag with
the result of the condition followed by a single compare with zero and
a jump. Better code would be two compares and two jumps.
The gimple is
_1 = cond1 == 2048;
_2 = cond2 == 8;
_3 = _1 | _2;
if (_3 != 0) goto ; else goto ;
...
so this poor code sequence is essentially a correct translation.
On MIPS, for the same test case, the gimple is different:
if (cond1 == 2048) goto ; else goto ;
:
if (cond2 == 8) goto ; else goto ;
:
...
which generates the better code sequence.
Can someone give me a pointer where to find where the lowering
pass decides to break up a condition into multiple tests? Is
there a target configuration option which I have overlooked or
maybe set incorrectly?
BRANCH_COST, which comes into play during generation of the initial
trees as well in passes which try to optimize branchy code into
straighter code.
Thanks. I did look at BRANCH_COST, and played with the values, but it
didn't seem to have any affect. I'll take a closer look.
Look at LOGICAL_OP_NON_SHORT_CIRCUIT . By defualt, it is defined as:
(BRANCH_COST (optimize_function_for_speed_p (cfun), \
false) >= 2)
But MIPS defines it as 0.
Changing LOGICAL_OP_NON_SHORT_CIRCUIT to 0 will disable this optimization.
LOGICAL_OP_NON_SHORT_CIRCUIT controls both places where (cond1 == 2048
|| cond2 == 8) would remove the branch.
NOTE I think MIPS defines LOGICAL_OP_NON_SHORT_CIRCUIT incorrectly but
that is a different story.
Thanks,
Andrew Pinski
I set BRANCH_COST to 1 for both predicted and non-predicted branches.
This generates the shorter sequence with a compare, but I'm concerned
that it will adversely affect code generation elsewhere. Branches are
higher cost than simple instructions.
Looking at the code generated with BRANCH_COST > 1, it doesn't do what
I indicated above. This did not reduce the number of branches.
In both cases there are two branches in this short test case. When
BRANCH_COST > 1, there are three instructions to do a compare vs one
when BRANCH_COST = 1. I'm at a loss to see where there is any benefit.
I'll take a look at the LOGICAL_OP_NON_SHORT_CIRCUIT settings and see
if this makes a difference.
--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
gcc-7-20181129 is now available
Snapshot gcc-7-20181129 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20181129/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 266649 You'll find: gcc-7-20181129.tar.xzComplete GCC SHA256=94614bb365d5759e79415c0bf88dcb5f2155bc7c66b1ea8c203b893161ea44c6 SHA1=1c6874f0d2e7f34846e5b926d5d94dbeeba72802 Diffs from 7-20181122 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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.
Re: GCC 7.4 Release Candidate available from gcc.gnu.org
On 11/29/18 04:24, Richard Biener wrote: A release candidate for GCC 7.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/7.4.0-RC-20181129/ and shortly its mirrors. It has been generated from SVN revision 266611. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release GCC 7.4 at the end of next week. I bootstrapped and tested on powerpc64le-unknown-linux-gnu and powerpc64-unknown-linux-gnu and all went well. -- -Bill Seurer
Help Out with Gcc
Greetings All, I assume you get lots of these but I was wondering what's the areas where gcc needs help the most these days that are good for a new developer to gcc. The only other question I have is the gcc internal manual here up to date for gcc 8 or not? https://gcc.gnu.org/onlinedocs/gccint/index.html#SEC_Contents Thanks, Nick
Re: Gimpel lowering question.
On Wed, Nov 28, 2018 at 6:10 PM Jeff Law wrote:
>
> On 11/28/18 10:00 AM, Michael Eager wrote:
> > I have a small test case which generates poor quality code on my target.
> > Here is the original:
> >
> > if (cond1 == 2048 || cond2 == 8)
> > {
> > x = x + y;
> > }
> > return x;
> >
> > This ends up generating a series of instructions to compute a flag with
> > the result of the condition followed by a single compare with zero and
> > a jump. Better code would be two compares and two jumps.
> >
> > The gimple is
> >
> > _1 = cond1 == 2048;
> > _2 = cond2 == 8;
> > _3 = _1 | _2;
> > if (_3 != 0) goto ; else goto ;
> > ...
> >
> > so this poor code sequence is essentially a correct translation.
> >
> > On MIPS, for the same test case, the gimple is different:
> >
> > if (cond1 == 2048) goto ; else goto ;
> > :
> > if (cond2 == 8) goto ; else goto ;
> > :
> > ...
> >
> > which generates the better code sequence.
> >
> > Can someone give me a pointer where to find where the lowering
> > pass decides to break up a condition into multiple tests? Is
> > there a target configuration option which I have overlooked or
> > maybe set incorrectly?
> BRANCH_COST, which comes into play during generation of the initial
> trees
Sth I don't like very much... maybe we can revisit removing
the few cases in fold-const.c (thus GENERIC folding) and rely
on later GIMPLE passes instead plus on RTL expansion to
do the reverse transform.
Not for GCC 9 of course.
>as well in passes which try to optimize branchy code into
> straighter code.
>
> jeff
