On 8/17/23 3:54 AM, Richard Biener wrote:
I think it needs a new category, 'inline' is probably the "closest" existing one
but that also tends to be noisy. Maybe 'call' would be a good name? We could
report things like tail-recursion optimization, tail-calling and sibling calling
optimizations
First, if this is no longer the appropriate group for this discussion,
please tell me where to send it.
I've been working to understand all the comments here. From them, I think:
1. It's OK to have gcc report back to the user whether each particular
call in tail position is optimized when
Thank you for your comments. I have a few questions.
I don't think this specific case qualifies for -Wdisabled-optimization.
The diagnostic is for cases the user can control and was invented
for limits we put up for compile-time and memory-usage issues
where there exist --param XYZ to adjust
On 8/5/23 5:53 PM, David Malcolm wrote:
...but the warning branch uses "warning", which implicitly uses the
input_location global variable. Is the warning reported at the correct
place? It's better to use warning_at and pass it the location at which
the warning should be emitted.
Thanks, I
On 8/5/23 4:58 PM, Prathamesh Kulkarni wrote:
I don't have comments on the patch, but a new warning will also
require a corresponding entry in doc/invoke.texi.
Thank you for your comment.
-Wdisabled-optimization is an established warning, it's just that I'd
like it to apply in another
The patch at the end adds a warning when a tail/sibling call cannot be
optimized for various reasons.
I built and tested GCC with and without the patch with configuration
Configured with: ../../gcc-mainline/configure --enable-languages=c
--disable-multilib --prefix=/pkgs/gcc-mainline
On 11/12/2015 12:08 PM, Bradley Lucier wrote:
On 11/12/2015 11:57 AM, Bernd Schmidt wrote:
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up
On 11/12/2015 11:57 AM, Bernd Schmidt wrote:
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up it a bit now.
{
+ unsigned int memory_request =
This patch (a) removes an exact copy of is_too_expensive from cprop.c,
(b) renames is_too_expensive in gcse.c to
gcse_or_cprop_is_too_expensive, (c) expands the warning in
gcse_or_cprop_is_too_expensive to say how much --param max-gcse-memory
needs to be increased, and (d) increases the
