Re: __attribute__((early_branch))
On Thu, May 2, 2019 at 6:16 PM Segher Boessenkool wrote: > > On Thu, May 02, 2019 at 02:17:51PM +0200, Richard Biener wrote: > > On Tue, Apr 30, 2019 at 9:53 PM Jeff Law wrote: > > > This is loop unswitching. It's a standard GCC optimization. If it's > > > not working as well as it should, we're far better off determining why > > > and fixing the automatic transformation rather than relying on > > > attributes to drive the transformation. > > > > It's currently not implemented for switch () stmts, just for conditionals. > > This also hurts SPEC cactusADM. There might be a missed-optimization > > bug about this. A simple recursive implementation might be possible; > > unswitch one case at a time - maybe order by profile probability. We > > already recurse on the unswitched bodies (in case multiple conditions > > can be unswitched) > > Well, if for some case value we can prove the controlling expression is > constant in the loop, we can almost always prove it is constant without > looking at the case value? So we can pull the whole switch statement > outside just as easily? There isn't any infrastructure to "easily" do that (copy the loop N times, wrap it in a switch stmt and put the N loop copies into the switch cases). The infrastructure we have (loop versioning) manages to copy a loop once and wrap the two copies with a conditional. It might be also preferable to only unswitch the most frequently executed case to avoid code size explosion (IIRC the cactusADM case has 4 cases, only one is actually executed). Richard. > > > Segher
Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?
On 02/05/19 16:33, Segher Boessenkool wrote:
> On Thu, May 02, 2019 at 01:02:14PM +, Matthew Malcomson wrote:
>> On 01/05/19 20:40, Segher Boessenkool wrote:
>>> On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote:
On 4/30/19 11:24 AM, Matthew Malcomson wrote:
> That was why I ended up suggesting multiple notes -- it's currently
> trying to satisfy more than one criteria and they're not quite compatible.
Well, we obviously have to keep arg setup, asan, stack protector and
nonlocal stuff in the same relative order, but I believe they should all
ultimately land before the NOTE_INSN_FUNCTION_BEG. THe question is how
to make that happen :-)
>>>
>>> The current meaning of NOTE_INSN_FUNCTION_BEG is
>>>
>>> /* Indicate the beginning of the function body,
>>>as opposed to parm setup. */
>>> emit_note (NOTE_INSN_FUNCTION_BEG);
>>>
>>> (function.c), and half of the things that use the note think that
>>> everything before it is argument setup, and nothing after it is.
>>>
>>> Just adding extra notes isn't enough afaics; some surgery is needed.
>>
>> Apologies, I don't follow -- could you elaborate on why an extra note is
>> not enough?
>>
>> If this note is trying to mark the end of the argument setup for those
>> places you mention, and the start of user code for debug output, and
>> those are not the same place then I would have thought splitting it
>> would be necessary.
>
> Because other things want to use it as the place to put stack checking,
> for example. And that cannot be after this note, but it can also not
> be before it.
>
I figured the stack checking could be after one note (end of argument
setup), and before the other (start of user code)?
> Is there any reason the stack checking code is inserted way before the
> prologue/epilogue are, btw?
>
I don't know, I'm especially curious why the prologue & epilogue are
emitted in assembly with the TARGET_ASM_FUNCTION_{EPILOGUE,PROLOGUE}
macros instead of emitted as rtl somewhere earlier in the pipeline.
I'd guess the stack checking code is earlier since it would like to be
optimised by the RTL passes.
Are you thinking there's call for a more thorough handling of the
introduction and placement of these almost-prologue parts like
stack-checking, non-local goto save areas and the like?
>
> Segher
>
GCC 9.1 Released
We are proud to announce the next, major release of the GNU Compiler Collection. If you want to boost your software with a fresh new compiler, with new language features, various new optimizations, improvements to old optimizations, GCC 9.1 is here for you! GCC 9.1 is a major release containing substantial new functionality not available in GCC 9.x or previous GCC releases. In this release C++17 support is no longer marked experimental. The C++ front-end implements the full C++17 language (already previous GCC major version implemented that) and the C++ standard library support is almost complete. The C++ front-end and library also have numerous further C++2a draft features [1]. GCC has a new front-end for the D language. GCC 9.1 has newly partial OpenMP 5.0 support and almost complete OpenACC 2.5 support. On the optimization side, the link time and inter-procedural optimizations have been made more scalable [2]. There have been various usability improvements in GCC diagnostics and GCC 9.1 features various new warnings [3]. Some code that compiled successfully with older GCC versions might require source changes, see http://gcc.gnu.org/gcc-8/porting_to.html for details. See https://gcc.gnu.org/gcc-9/changes.html for more information about changes in GCC 9.1. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-9.1.0/ subdirectory. If you encounter difficulties using GCC 9.1, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. Driving a leading free software project such as GNU Compiler Collection would not be possible without support from its many contributors. Not to only mention its developers but especially its regular testers and users which contribute to its high quality. The list of individuals is too large to thank individually! Please consider a donation to the GNU Toolchain Fund to support the continued development of GCC! [1] See https://gcc.gnu.org/projects/cxx-status.html, https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017 and https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020 [2] See http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html [3] See https://developers.redhat.com/blog/2019/03/08/usability-improvements-in-gcc-9/
Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?
On Fri, May 03, 2019 at 09:29:11AM +, Matthew Malcomson wrote:
> On 02/05/19 16:33, Segher Boessenkool wrote:
> > Because other things want to use it as the place to put stack checking,
> > for example. And that cannot be after this note, but it can also not
> > be before it.
> >
>
> I figured the stack checking could be after one note (end of argument
> setup), and before the other (start of user code)?
I don't think that can work. It needs to do its thing before anything
else (that can overflow, at least) touches the stack.
> > Is there any reason the stack checking code is inserted way before the
> > prologue/epilogue are, btw?
>
> I don't know, I'm especially curious why the prologue & epilogue are
> emitted in assembly with the TARGET_ASM_FUNCTION_{EPILOGUE,PROLOGUE}
> macros instead of emitted as rtl somewhere earlier in the pipeline.
They are emitted as RTL on most targets. Some targets *also* use some
asm text output for special things, but the usual prologue code is done
as RTL.
> I'd guess the stack checking code is earlier since it would like to be
> optimised by the RTL passes.
It cannot, or *should* not, be optimised much. Hrm.
> Are you thinking there's call for a more thorough handling of the
> introduction and placement of these almost-prologue parts like
> stack-checking, non-local goto save areas and the like?
I think we should try to no longer rely on these magic notes, which only
still work by luck, or even do nbot really work anymore.
Segher
gcc-8-20190503 is now available
Snapshot gcc-8-20190503 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190503/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 270862 You'll find: gcc-8-20190503.tar.xzComplete GCC SHA256=d3e69578dd5295f0289d3eb1a8d6448c21671833adbd6f135da11feb9c310f63 SHA1=d68a8e6d77b232a81f6f94918d9e11fcd1db0bc9 Diffs from 8-20190426 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
