On 07/13/2016 05:29 PM, Dominik Vogt wrote:
Unfortunately this patch (or whatever got actually committed) has
broken the gcc.target/s390/pr679443.c test case, which is a bit
fishy (see code snippet below). I assign most registers to global
variables and then use some complicated arithmetics wit
On 07/14/2016 04:53 PM, Jakub Jelinek wrote:
2016-07-14 Jakub Jelinek
PR c/71858
* c-common.h (enum lookup_name_fuzzy_kind): Add
FUZZY_LOOKUP_FUNCTION_NAME.
* c-decl.c (implicit_decl_warning): Use FUZZY_LOOKUP_FUNCTION_NAME
instead of FUZZY_LOOKUP_NAM
On 07/14/2016 11:10 AM, Dominik Vogt wrote:
- if (flag_stack_usage_info)
-stack_usage_size += extra;
+ /*!!!*/
+ if (flag_stack_usage_info && pstack_usage_size)
+*pstack_usage_size += extra;
What does the comment mean? Whatever it is needs to be addressed and the
comment removed.
I still have misgivings about all the changes needed to the following
passes, but I guess there's no choice but to live with it. So, I'm
trying to look at this patch, but I'm finding it fairly impenetrable and
underdocumented.
+ /* The concerns for which we want a prologue placed on this BB.
On 06/22/2016 05:37 AM, Jeff Law wrote:
It looks like this stalled...
Anyway, it's fine for the trunk.
Some of the surrounding code was changed a bit to produce different
errors for different C standards, so I had to make an adjustment to the
patch. While I was here, I added cdw_atomic to th
On 07/15/2016 02:22 PM, Dominik Vogt wrote:
Final version 6 with the stray comment removed (was a harmless
oversight).
Ok, let's put it in.
Bernd
On 07/15/2016 07:07 PM, Bin Cheng wrote:
Bootstrap and test on x86_64. Is it OK?
If you do this you'll also need to remove the use in config/bfin.
Bernd
On 07/14/2016 05:11 PM, Georg-Johann Lay wrote:
The hook allows better diagnostics: The address spaces are registered
with c_register_addr_space and if the parser comes across an address
space it provides the hook with the needed information, in particular
the location of the token so that the m
The motivating example for this patch was a change that was submitted
for genattrtab last year, which would have made us generate
switch (type = get_attr_type (insn))
{
... some cases ...
default:
switch (type = get_attr_type (insn)))
{
... some other cases ...
On 07/18/2016 06:34 PM, Segher Boessenkool wrote:
+ /* The frequency of executing the prologue for this BB and all BBs
+ dominated by it. */
+ gcov_type cost;
Is this frequency consideration the only thing that attempts to prevent
placing prologue insns into loops?
Yes. The algorith
On 07/19/2016 10:07 AM, Richard Biener wrote:
This is not appropriate for CFG cleanup due to its complexity not
being O(# bbs + # edges).
I tried hard in the past to make it so (at least when no transform is done).
Why wouldn't it be, if no transform is done? Assuming we visit each bb
once, w
On 07/19/2016 12:09 PM, Richard Biener wrote:
I saw walks over stmts of a BB. IMHO that's a no-go.
Only to find the first or last nondebug one. Is that unacceptable?
I'm thinking of
switch (a)
{
...
case n:
do-stuff;
default:
switch (a)
{
case n:
On 07/19/2016 12:22 PM, Marc Glisse wrote:
On Tue, 19 Jul 2016, Bernd Schmidt wrote:
On 07/19/2016 12:09 PM, Richard Biener wrote:
I saw walks over stmts of a BB. IMHO that's a no-go.
Only to find the first or last nondebug one. Is that unacceptable?
On 07/19/2016 12:35 PM, Richard Biener wrote:
I think that start/end_recording_case_labels also merged adjacent labels
via group_case_labels_stmt. Not sure why you need to stop recording
case labels during the transform. Is this because you are building a new
switch stmt?
It's because the ca
On 07/19/2016 04:46 PM, Segher Boessenkool wrote:
But you need the profile to make even reasonably good decisions.
I'm not worried about making cost decisions: as far as I'm concerned
it's perfectly fine for that. I'm worried about correctness - you can't
validly save registers inside a loop
On 07/19/2016 10:16 AM, Georg-Johann Lay wrote:
Done. Attached is the updated version of the change, log entry is the
same as before.
Johann
LGTM.
Bernd
On 07/19/2016 01:18 PM, Richard Biener wrote:
On Tue, Jul 19, 2016 at 1:07 PM, Bernd Schmidt wrote:
On 07/19/2016 12:35 PM, Richard Biener wrote:
I think that start/end_recording_case_labels also merged adjacent labels
via group_case_labels_stmt. Not sure why you need to stop recording
case
On 07/19/2016 05:35 PM, Segher Boessenkool wrote:
On Tue, Jul 19, 2016 at 04:49:26PM +0200, Bernd Schmidt wrote:
But you need the profile to make even reasonably good decisions.
I'm not worried about making cost decisions: as far as I'm concerned
it's perfectly fine for th
On 07/19/2016 10:20 AM, Richard Biener wrote:
I like it. Improving re-build time in my dev tree is very much
welcome, and yes,
libbackend build time is a big part of it usually (plus of course cc1
link time).
Since that wasn't an entirely explicit ack, I'll add mine. Thank you for
doing this.
On 07/20/2016 11:51 AM, James Greenhalgh wrote:
2016-07-20 James Greenhalgh
* target.def (max_noce_ifcvt_seq_cost): New.
* doc/tm.texi.in (TARGET_MAX_NOCE_IFCVT_SEQ_COST): Document it.
* doc/tm.texi: Regenerate.
* targhooks.h (default_max_noce_ifcvt_seq_cost)
On 07/20/2016 02:25 PM, Uros Bizjak wrote:
2016-07-19 14:46 GMT+02:00 Uros Bizjak :
The result of exercises with sed in gcc/ directory.
Some more conversions:
2016-07-20 Uros Bizjak
* cse.c: Use HOST_WIDE_INT_M1 instead of ~(HOST_WIDE_INT) 0.
* combine.c: Use HOST_WIDE_INT_M1U i
On 07/20/2016 06:09 PM, Jeff Law wrote:
So I'm going to let Richi run with the review on this one since the two
of you are already iterating. But I did have one comment on the
placement of the pass.
I believe one of the key things to consider for whether or not something
like this belongs in th
On 07/20/2016 11:16 PM, Uros Bizjak wrote:
As suggested by Jakub.
2016-07-20 Uros Bizjak
* hwint.h (HOST_WIDE_INT_0): New define.
(HOST_WIDE_INT_0U): Ditto.
* double-int.c: Use HOST_WIDE_INT_0 instead of (HOST_WIDE_INT) 0.
* dse.c: Use HOST_WIDE_INT_0U instead of (unsigned HO
On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
bool
+gimple_alloca_call_p (const gimple *stmt)
+{
+ tree fndecl;
+
+ if (!is_gimple_call (stmt))
+return false;
+
+ fndecl = gimple_call_fndecl (stmt);
+ if (fndecl && DECL_BU
On 07/20/2016 06:39 PM, James Greenhalgh wrote:
On Wed, Jul 20, 2016 at 01:41:39PM +0200, Bernd Schmidt wrote:
How about wrapping the param value into COSTS_N_INSNS, to make the
value of the param less dependent on compiler internals?
I did consider this, but found it hard to word for the
On 07/22/2016 01:15 PM, Jakub Jelinek wrote:
@@ -32335,6 +32341,7 @@ rs6000_handle_altivec_attribute (tree *node,
case V4SImode: case V8HImode: case V16QImode: case V4SFmode:
case V2DImode: case V2DFmode:
result = type;
+ gcc_fallthrough ();
default: brea
On 07/22/2016 05:19 PM, Alexander Monakov wrote:
I hope I've satisfactorily explained the failures you've pointed out (thanks for
the data). I think I should leave the choice of what to do next (revert the
patch or leave it in and install fixups where appropriate) up to you?
What's the motivat
On 07/28/2016 03:26 PM, Marek Polacek wrote:
Many attributes that accept integer constant as a parameter call
default_conversion for such constants to perform the usual arithmetic
conversions. The call to default_conversion is always guarded so as
to prevent a NULL_TREE, an IDENTIFIER_NODE, or a
On 07/28/2016 03:19 PM, Marek Polacek wrote:
Since r157233, build_compound_literal will return error_mark_node for
erroneous initializers of compound literals. This caused an ICE in
c_parser_postfix_expression_after_paren_type because the code dealing
with evaluating variably modified types wasn
On 07/28/2016 09:33 AM, Senthil Kumar Selvaraj wrote:
Is there a reason why only REG and SYMBOL_REFs get valid
subreg_in_class? I tried extending it handle constants and PLUS
expressions, and it fixes PR 71873. It also fixes a another
bug that was a work around for the reload failure (PR
On 07/29/2016 02:30 PM, Aldy Hernandez wrote:
+/* Max number of alloca bytes per call before we must switch to malloc.
+
+ ?? Swiped from gnulib's regex_internal.h header. Is this actually
+ the case? This number seems arbitrary, though sane.
+
+ The OS usually guarantees only one guard p
On 07/29/2016 05:07 PM, Aldy Hernandez wrote:
There is currently only one use, but I was thinking that perhaps if
there were other alloca uses added later (I hope not), that they could
all use the same macro. But I am more than happy to place this
definition it in it's only use file for now, if t
On 08/01/2016 10:44 PM, Joseph Myers wrote:
On Fri, 22 Jul 2016, Bernd Schmidt wrote:
What's the motivation for supporting -fno-toplevel-reorder anyway? That's
practically just a legacy mode as far as I know.
It's for code that uses toplevel asms in ways for which it mat
On 11/24/2016 03:21 PM, Segher Boessenkool wrote:
Combine uses insn_rtx_cost extensively. I have tried to change it to use
the full rtx cost, not just the source cost, a few times before, and it
always only regressed. Part of it is that most ports' cost calculations
are, erm, not so great -- e
On 11/24/2016 03:36 PM, Segher Boessenkool wrote:
On Thu, Nov 24, 2016 at 03:26:45PM +0100, Bernd Schmidt wrote:
On 11/24/2016 03:21 PM, Segher Boessenkool wrote:
Combine uses insn_rtx_cost extensively. I have tried to change it to use
the full rtx cost, not just the source cost, a few times
On 11/24/2016 03:53 PM, Segher Boessenkool wrote:
Your own 2/3 shows my point: you needed fixes to the i386 port for it
to behave sanely after this 1/3; what makes you think other ports are
not in the same boat?
When I realized i386 was broken I had a look at aarch64 and it looked
sane, and t
On 11/25/2016 04:55 PM, Segher Boessenkool wrote:
So IMNSHO this rtx costing change belongs in early stage 1, and should
be reverted.
Done.
Bernd
On 11/25/2016 04:55 PM, Segher Boessenkool wrote:
So IMNSHO this rtx costing change belongs in early stage 1, and should
be reverted.
Done.
Bernd
Been looking at this off and on, and I'm still not sure I entirely get
it - sorry.
On 11/11/2016 10:15 PM, David Malcolm wrote:
Implementing an RTL frontend by using the RTL reader from read
-rtl.c
means that we now need a diagnostics subsystem on the *host* for
handling errors in RTL files, ra
On 11/28/2016 07:50 PM, Jeff Law wrote:
So how would you suggest this be fixed right now? I'd really like to
get the regression addressed.
The regression is still fixed. That wasn't the case at all stages while
I was working on it, but the i386 patch seems to suffice now.
I would claim tha
On 11/29/2016 06:20 PM, David Malcolm wrote:
if that distinction makes sense. Clearly we already have a diagnostics
subsystem on the host; what this patch is adding is the separate, rtl-s
pecific diagnostic subsystem to cc1 on the host.
So that still seems odd to me. Why not use the normal di
On 11/29/2016 07:53 PM, David Malcolm wrote:
Would you prefer that I went with approach (B), or is approach (A)
acceptable?
Well, I was hoping there'd be an approach (C) where the read-rtl code
uses whatever diagnostics framework that is available. Maybe it'll turn
out that's too hard. Someh
On 11/30/2016 01:02 PM, Jakub Jelinek wrote:
I've discovered today that RTL sharing verification has been disabled for
the last 3.5 years. My --enable-checking=yes,rtl,extra bootstraps on
x86_64-linux and i686-linux revealed only two bugs.
Ok for both patches.
Bernd
On 11/29/2016 10:13 PM, Bernd Schmidt wrote:
On 11/29/2016 07:53 PM, David Malcolm wrote:
Would you prefer that I went with approach (B), or is approach (A)
acceptable?
Well, I was hoping there'd be an approach (C) where the read-rtl code
uses whatever diagnostics framework that is avai
On 11/30/2016 11:11 PM, Jakub Jelinek wrote:
I run into the problem that while simplify_replace_rtx if it actually does
copy_rtx (for y) or if it simplifies something through
simplify_gen_{unary,binary,relational,ternary}, the used bits on the newly
created rtxes are cleared, when we fall through
On 12/01/2016 11:12 AM, Dominik Vogt wrote:
diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c
index 77e6b05..5370602 100644
--- a/gcc/print-rtl.c
+++ b/gcc/print-rtl.c
@@ -371,7 +371,10 @@ rtx_writer::print_rtx_operand_code_i (const_rtx in_rtx,
int idx)
if (INSN_HAS_LOCATION (in_insn))
On 11/21/2016 01:36 PM, Dominik Vogt wrote:
diff --git a/gcc/combine.c b/gcc/combine.c
index b22a274..457fe8a 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5575,10 +5575,23 @@ combine_simplify_rtx (rtx x, machine_mode op0_mode, int
in_dest,
{
rtx cop1 = const0_rtx;
On 11/30/2016 09:24 PM, David Malcolm wrote:
gcc/ChangeLog:
* read-md.c (have_error): New global, copied from errors.c.
(fatal): New function, copied from errors.c.
I would have expected the function to go into diagnostic.c, but actually
there are already various functions of
On 11/11/2016 10:15 PM, David Malcolm wrote:
+ /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so that
+ flag_self_test contains the path to the selftest subdirectory of the
+ source tree (without a trailing slash). Copy it up to
+ path_to_selftest_files, to avoid self
On 11/11/2016 10:15 PM, David Malcolm wrote:
#include "gt-aarch64.h"
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6c608e0..0dda786 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
I think we should separate out the target specific tests so as to give
port
On 12/01/2016 11:43 PM, Jakub Jelinek wrote:
so we'd need to slow shallow_copy_rtx down by adding switch (code)
in there or something similar.
Is there reason to assume it's time-critical? IMO eliminating the
potential for error by not having callers need to do this outweighs that
concern.
On 12/02/2016 02:25 PM, Nathan Sidwell wrote:
+/* Check if we've met the maximum error limit. */
Arguments should be documented.
+void
+diagnostic_check_max_errors (diagnostic_context *context, bool flush)
+{
+ if (!context->max_errors)
+return;
I prefer to spell that as != 0 since i
On 12/02/2016 03:00 AM, David Malcolm wrote:
Changed in v6:
- split out dump-reading selftests into followup patches
(target-independent, and target-specific)
- removes unneeded headers from read-rtl-function.c
- numerous other cleanups identified in review
Ok, starting to look very close to
On 12/02/2016 03:12 PM, Jakub Jelinek wrote:
--- gcc/rtl.c.jj2016-10-31 13:28:12.0 +0100
+++ gcc/rtl.c 2016-12-02 11:01:12.557553040 +0100
@@ -318,10 +318,6 @@ copy_rtx (rtx orig)
us to explicitly document why we are *not* copying a flag. */
copy = shallow_copy_rtx (or
Conceptually, the concept of "target-independent RTL" seems weird to me.
But I guess you expect these to work because the backend never gets
involved trying to recognize insns or addressing modes? I think a
comment to that effect somewhere near the C code to load these tests
would be good.
I
On 12/01/2016 10:43 PM, David Malcolm wrote:
+ rtx_insn *jump_insn = get_insn_by_uid (1);
+ ASSERT_EQ (JUMP_INSN, GET_CODE (jump_insn));
+ ASSERT_EQ (ret_rtx, JUMP_LABEL (jump_insn));
+ // FIXME: ^^^ use ASSERT_RTX_PTR_EQ here ^^^
Why is this a fixme and not just done that way (several inst
On 12/02/2016 02:37 AM, David Malcolm wrote:
Here's the current status of the kit:
"[PATCH 1/9] print_rtx: implement support for reuse IDs (v2)"
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01188.html
Still needs review
Whoops, I thought this was settled. Ok for the new version.
Bernd
With the i386 backend no longer double-counting the cost of a SET, the
default implementation default_max_noce_ifcvt_seq_cost now provides too
high a bound for if conversion, allowing very costly substitutions.
The following patch fixes this by making an i386 variant of the hook,
but first - J
On 12/02/2016 07:44 PM, David Malcolm wrote:
The two flag assignments don't seem to be needed; I think this is due
to adding:
if (node->native_rtl_p ())
node->force_output = 1;
to cgraph_node::finalize_function in patch 9.
Should I lose them (and the comment)?
Let's keep this patch sel
On 12/05/2016 07:02 PM, Prathamesh Kulkarni wrote:
This patch folds strstr (s, t) eq/ne s to strcmp (s, t) eq/ne 0 if
strlen (t) is known.
That's not the same thing, is it?
s = "hello world", t = "hello":
strstr (s, t) == s, but not strcmp (s, t) == 0.
I think you'd want memcmp (s, t, strle
On 12/02/2016 09:24 PM, David Malcolm wrote:
gcc/ChangeLog:
* selftest-rtl.c (selftest::assert_rtx_ptr_eq_at): New function.
* selftest-rtl.h (ASSERT_RTX_PTR_EQ): New macro.
Ok.
Bernd
On 12/03/2016 12:07 AM, David Malcolm wrote:
seen_error is already implemented in the "real" diagnostic subsystem,
and would be a clash: we want a way to determine if read-md.c's
implementation of error_at was called. Hence it seems simplest to
conditionally add a copy of the "have_error" globa
In this PR, we have two registers with "replace" set for them. When
processing the first, we delete its setter, which happens to be the only
use of the other register. In the second iteration we then assert that
the other register has a use, which would be reasonable if we hadn't
deleted it.
On 10/28/2016 03:43 PM, Segher Boessenkool wrote:
On Fri, Oct 28, 2016 at 01:18:19PM +0200, Bernd Schmidt wrote:
In this PR, we manage to simplify the code down to
(lt (and (reg) (signbit)) (const 0))
simplify_comparison then calls make_compound_operation on the AND
expression, and that turns
On 12/06/2016 11:40 PM, Alan Modra wrote:
I understand that config/ in the gcc repository is the master source
for binutils-gdb config/. If that's the case then people removing
gcc support for particular targets need to be careful about their
config/ edits. If a target is still supported in bin
On 12/07/2016 12:56 PM, Segher Boessenkool wrote:
On Wed, Dec 07, 2016 at 10:31:14AM +, James Greenhalgh wrote:
We always keep the entries in the constant pool after we first see them, and
we figure out what gets used in the constant pool by sweeping through
looking for referenced entries. T
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while scanning.
Bootstrapped and tested on x86_64-linux, and reportedly fixes the
problem on ppc, ok?
Bernd
PR rtl-opt
On 12/08/2016 04:01 AM, David Malcolm wrote:
gcc/ChangeLog:
* read-md.c (md_reader::read_name_1): Write out the location of
the start of the name, rather than the end, eliminating
unread_char and read_char calls.
For avoidance of doubt, ok to check in the currently appro
On 12/08/2016 09:39 PM, David Malcolm wrote:
OK as adjustments to patches 8a and 8b?
Ok. Is it possible to adjust these macros to return something like a
const reference to ensure people can't make this kind of error?
Bernd
On 12/09/2016 03:02 AM, David Malcolm wrote:
The following patch leads to errors like this for that kind
of mistake:
error: assignment of member 'mem_attrs::offset' in read-only object
MEM_OFFSET (x) = atoi (name.string);
^
Successfully bootstra
On 12/08/2016 10:47 PM, David Malcolm wrote:
Is (A) OK, or would you prefer (B)? (I prefer (A) fwiw)
Oh well, just keep it as it is.
Bernd
On 12/03/2016 10:49 AM, Uros Bizjak wrote:
Based on the above explanation, the patch is OK.
I'll be treating the ifcvt part of it as obvious. However, testing
showed an issue with the i386 funcspec-11 test:
/* PR target/36936 */
/* { dg-do compile } */
/* { dg-require-effective-target ia32
On 12/09/2016 03:03 PM, Andre Vieira (lists) wrote:
This patch fixes the issue reported in PR78255 by making postreload
aware it should not be performing CSE on functions if NO_FUNCTION_CSE is
defined to true.
Bootstrap and full regression on arm-none-linux-gnueabihf and
aarch64-unknown-linux-gn
On 12/09/2016 04:34 PM, Andre Vieira (lists) wrote:
Regardless, the other testcases I add in this patch show a sub-optimal
transformation done by postreload, turning direct calls into indirect
calls, for targets which have specifically pointed out that no CSE
should be done on functions through
On 12/09/2016 05:16 PM, Andre Vieira (lists) wrote:
Regardless, 'reload_cse_simplify' would never perform the opposite
transformation. It checks whether it can replace anything within the
first argument INSN, with the second argument TESTREG. As the name
implies this will always be a register.
On 10/27/2016 12:29 AM, Cesar Philippidis wrote:
Currently, the nvptx backend is only neutering the worker axis when
propagating variables used in conditional expressions across the worker
and vector axes. That's a problem with the worker-state spill and fill
propagation implementation because al
On 12/10/2016 08:58 PM, Segher Boessenkool wrote:
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while
On 12/09/2016 08:32 PM, David Malcolm wrote:
Thanks. Unfortunately, applying the "locate_file" patch
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01186.html
would now introduce a regression in a recently-added test case:
The problem is that this DejaGnu test case uses -fself-test, and
does
On 12/12/2016 03:21 PM, Bernd Schmidt wrote:
On 12/10/2016 08:58 PM, Segher Boessenkool wrote:
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop
On 12/15/2016 05:51 PM, Jakub Jelinek wrote:
This patch fixes what I've found quickly, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
Ok.
Bernd
On 12/14/2016 05:57 PM, David Malcolm wrote:
Any preferences? (or other syntax ideas?). My preference is one of the
currently-unused sigils e.g. "@3", or to wrap them in braces "{3}".
Either might work, I'd vaguely prefer <3> over {3} but they're
equivalent really. Maybe using "@" is simplest
On 12/16/2016 12:49 PM, Marek Polacek wrote:
But as this testcase shows, this breaks when the default label shares a label
with another case. On this testcase, when we reach the switch, we know that
argc is either 1, 2, or 3. So by the time we reach vrp2, the IR will have
been optimized to
On 12/16/2016 09:18 PM, David Malcolm wrote:
The following patch implements the change for print-rtl.c.
OK for trunk assuming it passes bootstrap®rtest?
Yes.
Bernd
I'll consider myself agnostic as to whether this is a feature we want or
need, so I'll just comment on some style questions. There's a fair
amount of coding style violations, I'll point some of them out but
please read the documents we have linked on this page:
https://gcc.gnu.org/contribute.
On 03/28/2016 06:44 AM, Andi Kleen wrote:
From: Andi Kleen
Extend the existing bprob and tree-prof tests to also run with autofdo.
The test runtimes are really a bit too short for autofdo, but it's
a reasonable sanity check.
This only works natively for now.
dejagnu doesn't seem to support a
On 04/27/2016 05:16 PM, H.J. Lu wrote:
This works for -m32, -mx32 and -m64. OK for trunk?
Yes, thanks.
Bernd
On 03/28/2016 06:44 AM, Andi Kleen wrote:
From: Andi Kleen
Add support for profiledbootstrap with autofdo. Will be useful
to get better testing coverage of autofdo.
Is this the only purpose? I'll admit this is the patch I like least out
of the series.
The autofdo'ed compiler is ~7% faster
On 03/28/2016 06:44 AM, Andi Kleen wrote:
This patch adds a new gcc-auto-profile script that figures out the
correct event and runs perf. The script is installed with on Linux systems.
That sounds useful, and I think we'll want to accept this.
So Linux just hardcodes installing the script, bu
On 04/15/2016 07:39 PM, Marcel Böhme wrote:
Sure. The updated patch, including Changelog and more test cases. Regression
tested.
This patch seems seriously damaged by sending it through the email body.
Please attach it (text/plain) instead.
Bernd
On 04/27/2016 07:03 PM, David Malcolm wrote:
Commit r210360 removed the first "i" field from the various instruction
nodes in rtx.def, moving it to an explicit "int insn_uid;" field
of the union "u2" within rtx_def.
Update the comment in rtl.def to reflect this change. Also, fix
a stray apost
On 04/27/2016 07:08 PM, David Malcolm wrote:
The various struct df_problem instances are constant data; mark them
as such.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu
OK for trunk?
gcc/ChangeLog:
* df-core.c (df_add_problem): Make the problem param be const.
(
On 04/27/2016 07:12 PM, David Malcolm wrote:
The function maybe_set_first_label_num acts on a CODE_LABEL; we can
capture that in the type system.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; it's
only used from stmt.c (not in any of the config subdirs), so I didn't
attempt a ma
On 04/27/2016 07:06 PM, David Malcolm wrote:
Whilst debugging an issue in df, I noticed that there are
some #define constants that could be an enum (thus making them known
to gdb).
Convert them to a new enum, and update the "id" field of
struct df_problem.
Successfully bootstrapped & regrtested
On 04/27/2016 10:59 PM, Jeff Law wrote:
PR rtl-optimization/44281
* hard-reg-set.h (struct target_hard_regs): New field
x_fixed_nonglobal_reg_set.
(fixed_nonglobal_reg_set): New macro.
* reginfo.c (init_reg_sets_1): Initialize it.
* ira.c (setup_alloc_regs): Use fixed_nong
On 04/28/2016 11:20 AM, Matthias Klose wrote:
On 27.04.2016 17:56, Dhole wrote:
I'm attaching the updated patch with the two minor issues fixed.
committed.
Something else that occurred to me - could you please also work on a
testcase?
Bernd
On 04/28/2016 12:08 PM, Jakub Jelinek wrote:
BTW, I think fatal_error doesn't make sense, it isn't something that is not
recoverable, normal error or just a warning would be IMHO more than
sufficient. The fallback would be just using current time, i.e. ignoring
the env var.
I thought about thi
On 04/28/2016 01:15 PM, Alexander Monakov wrote:
So if my understanding is correct, additional !cfun check can be acceptable as
a fix along the existing hack. Perhaps with a note about the nature of the
hack.
Yes, I think Thomas' patch is ok.
Bernd
On 04/28/2016 12:35 PM, Jakub Jelinek wrote:
On Thu, Apr 28, 2016 at 12:31:40PM +0200, Bernd Schmidt wrote:
I really don't see anything in that function that looks like a huge time
sink, so I'm not that worried about it. I think it's likely to be buried way
down in the noise.
On 04/28/2016 07:30 PM, Segher Boessenkool wrote:
In r193072 sbitmap_popcount was removed, so we cannot ask for the popcount
of an sbitmap anymore. Nothing calls sbitmap_alloc_with_popcount either.
This patch removes everything else popcount-related from sbitmap.
Tested on powerpc64-linux; is t
On 01/18/2016 10:22 AM, Richard Biener wrote:
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171 - the
inline expansion
for small sizes and equality compares should be done on GIMPLE. Today the
strlen pass might be an appropriate place to do this given its
superior knowledge
about strin
1301 - 1400 of 2198 matches
Mail list logo
