On 9/10/19 6:48 PM, Jakub Jelinek wrote:
> On Tue, Sep 10, 2019 at 05:46:14PM +0100, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>>> On Tue, Sep 10, 2019 at 06:14:11PM +0200, Martin Liška wrote:
On 9/9/19 11:14 PM, Joseph Myers wrote:
> On Mon, 9 Sep 2019, Jakub Jelinek wrote:
>
On Tue, 10 Sep 2019, Bernd Edlinger wrote:
> Hi!
>
> This ICE happens when compiling real_nextafter in real.c.
> CSE sees this:
>
> (insn 179 178 180 11 (set (reg:SI 319)
> (reg/v/f:SI 273 [ rD.73757 ])) "../../gcc-trunk-1/gcc/real.c":120:10
> 643 {*thumb2_movsi_vfp}
> (nil))
> [..
Hi!
My recent change broke Linux kernel build, where we ICE in get_nonzero_bits
which apparently assumes it must be called only on INTEGER_CSTs or
SSA_NAMEs, while during generic folding it can be called say with PLUS_EXPR
etc.
tree_nonzero_bits apparently can be called on any tree code, as it ha
Hi!
This testcase used to be vectorized before r260348, but isn't any longer.
The problem is that while we check with types_compatible_p:
/* We can only handle calls with arguments of the same type. */
if (rhs_type
&& !types_compatible_p (rhs_type, TREE_TYPE (op)))
we requir
On 9/10/19 10:52 AM, Bernhard Reutner-Fischer wrote:
> On 9 September 2019 15:41:05 CEST, "Martin Liška" wrote:
>> On 9/9/19 2:24 PM, Martin Liška wrote:
>>> Hi.
>>>
>>> The patch is about transition of and_comparisons_1 matching
>>> into match.pd.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu a
Jakub Jelinek writes:
> Hi!
>
> This testcase used to be vectorized before r260348, but isn't any longer.
> The problem is that while we check with types_compatible_p:
> /* We can only handle calls with arguments of the same type. */
> if (rhs_type
> && !types_compatible_p
Update my email address; the old one is my private one and still valid.
Cheers,
Tobias
Index: ChangeLog
===
--- ChangeLog (revision 275630)
+++ ChangeLog (working copy)
@@ -1,6 +1,10 @@
+2019-09-10 Tobias Burnus
+
+ *
On Wed, 11 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> My recent change broke Linux kernel build, where we ICE in get_nonzero_bits
> which apparently assumes it must be called only on INTEGER_CSTs or
> SSA_NAMEs, while during generic folding it can be called say with PLUS_EXPR
> etc.
>
> tree_nonze
On Wed, 11 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> This testcase used to be vectorized before r260348, but isn't any longer.
> The problem is that while we check with types_compatible_p:
> /* We can only handle calls with arguments of the same type. */
> if (rhs_type
> &&
On 9/10/19 1:19 PM, Marc Glisse wrote:
> (some quick comments, I didn't check in details)
Thanks for them.
>
> + (and:c (code1 @0 INTEGER_CST@1) (code2 @0 INTEGER_CST@2))
> [...]
> + (if (code1 == NE_EXPR && !val) (code2 @0 @2
>
> How about
>
> (and:c (code1 @0 INTEGER_CST@1)
On 9/11/19 10:22 AM, Li Jia He wrote:
> Hi,
>
> On 2019/9/10 3:40 PM, Martin Liška wrote:
>> On 9/9/19 3:55 PM, Richard Biener wrote:
>>> On Mon, 9 Sep 2019, Martin Liška wrote:
>>>
On 9/9/19 3:42 PM, Richard Biener wrote:
> There is no newly created GIMPLE?
Hm, I thought from t
Hi all, hi Jakub,
when playing around with offloading, I got an hsa initialization error
(/dev/... lacked write permission) and the library call returned with an
error status – but hsa_fns.hsa_status_string_fn didn't set the message
to the string variable.
Hence, the string variable was unin
On Wed, Sep 11, 2019 at 11:30:17AM +0200, Tobias Burnus wrote:
> when playing around with offloading, I got an hsa initialization error
> (/dev/... lacked write permission) and the library call returned with an
> error status – but hsa_fns.hsa_status_string_fn didn't set the message to
> the string
The MSP430 target has a "430X" extension which increases the directly
addressable memory range from 64KB (16-bit) to 1MB (20-bit).
This 1MB memory range is split into a "lower" region (below address 0x1)
and "upper" region (at or above address 0x1).
When data in the upper region is addresse
This fixes a wrong code generation on the ARM in very peculiar circumstances (
-O2 -fno-dce -fno-forward-propagate -fno-sched-pressure) present on all active
branches in the form of a missing zero-extension. It turns out that not all
parts of the RTL middle-end agree on the assumptions valid on
The following gets rid of __builtin_constant_p earlier to avoid
array-bound diagnostics on dead code. There's been enough optimization
on the fully inlined bodies so we can do that at the time of
array-bound diagnostics.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Ri
Hello.
One another updated version of the patch.
Changes from the previous version:
- I fixed:
gimple *stmt1 = (gimple *) XALLOCAVEC (char, gimple_size (GIMPLE_ASSIGN, 2));
into gimple_size (GIMPLE_ASSIGN, 3)
- I simplified condition in gimple_simplified_result_is_gimple_val
- optimize_vec_con
I'm sending updated version of the patch where I changed
from previous version:
- more compact matching is used (note @3 and @4):
(and (code1:c@3 @0 INTEGER_CST@1) (code2:c@4 @0 INTEGER_CST@2))
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Hi.
There's slightly updated version of the patch where
I use @3 and @4 in match.pd.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 997ed7390bb2897cf880b29d14d0e28e5f8873c2 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri,
Hi.
There's slightly updated version of the patch where
I use @3 and @4 in match.pd.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 00f3638c4ecf711edba9a92931a0835ab476c28c Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri,
The Microblaze target confuses unsigned long with HOST_WIDE_INT.
This works fine for many architectures, but fails on ARM (HOST_WIDE_INT is 8
bytes, unsigned long is 4 bytes). Leading to print a uninitialized register
instead of the desired number, fix by using the correct printf-specifier.
Teste
On 9/9/19 4:33 PM, Jan Hubicka wrote:
>> PING^1
>>
>> On 8/26/19 12:04 PM, Martin Liška wrote:
>>> Ok. I have a semi-working patch that has issues for inline clones.
>>> When we call cgraph_node::get_untransformed_body for an inline clone,
>>> then one needs to use clone_of->order to find proper LT
This was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1749578
* python/libstdcxx/v6/xmethods.py (SharedPtrUseCountWorker.__call__):
Fix syntax error.
Tested x86_64-linux (although I can't get tests for the use_count() or
unique() Xmethods to actually work ...)
Committ
* testsuite/20_util/result_of/sfinae_friendly_1.cc: Add -Wno-volatile
for C++2a and up. Define HAS_52748_FIXED and fix incorrect tests.
* testsuite/tr1/3_function_objects/result_of.cc: Add -Wno-volatile
for C++2a and up.
Tested x86_64-linux, committed to trunk.
co
On Wed, Sep 11, 2019 at 12:39:51PM +0200, Eric Botcazou wrote:
> This fixes a wrong code generation on the ARM in very peculiar circumstances
> (
> -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure) present on all
> active
> branches in the form of a missing zero-extension. It turns out
On 9/9/19 5:54 PM, Matthew Malcomson wrote:
> On 09/09/19 11:47, Martin Liška wrote:
>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>>> Hello,
>>>
>>> This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
>>> address sanitizer (HWASAN) in GCC. The document describing HWASAN can
Hi Eric,
On Wed, Sep 11, 2019 at 12:39:51PM +0200, Eric Botcazou wrote:
> This fixes a wrong code generation on the ARM in very peculiar circumstances
> (
> -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure) present on all
> active
> branches in the form of a missing zero-extension. It
Hi,
On Wed, Sep 11 2019, Jakub Jelinek wrote:
> On Wed, Sep 11, 2019 at 11:30:17AM +0200, Tobias Burnus wrote:
>> when playing around with offloading, I got an hsa initialization error
>> (/dev/... lacked write permission) and the library call returned with an
>> error status – but hsa_fns.hsa_sta
> What does it mean for
> (set (reg:QI) (const_int -128))
> for example? This is the canonical form of moving positive 128 into a
> register as well, of course.
Nothing, since word_register_operation_p returns false on CONST_INTs .
> W_R_O needs many more restrictions if it can work at all, bu
On Wed, 11 Sep 2019, Martin Liška wrote:
> Hello.
>
> One another updated version of the patch.
> Changes from the previous version:
> - I fixed:
> gimple *stmt1 = (gimple *) XALLOCAVEC (char, gimple_size (GIMPLE_ASSIGN,
> 2));
> into gimple_size (GIMPLE_ASSIGN, 3)
> - I simplified condition
On Wed, 11 Sep 2019, Martin Liška wrote:
> I'm sending updated version of the patch where I changed
> from previous version:
> - more compact matching is used (note @3 and @4):
> (and (code1:c@3 @0 INTEGER_CST@1) (code2:c@4 @0 INTEGER_CST@2))
>
> Patch can bootstrap on x86_64-linux-gnu and surv
When running libgo tests, when compiling the x_test package, this
patch forces the test package to be imported first. That ensures that
we will see the types defined in the test package before the types
defined in the non-test version of the package. This matters if the
types differ in some way,
On 8/16/19 2:09 PM, Jan Hubicka wrote:
>> On Thu, Aug 15, 2019 at 4:17 PM Jan Hubicka wrote:
>>>
On Tue, Aug 6, 2019 at 5:44 PM Martin Liska wrote:
>
>
> gcc/ChangeLog:
So I suppose this isn't to call operand_equal_p on two FIELD_DECLs
but to make two COMPONENT_REF
On Fri, 6 Sep 2019, Martin Liška wrote:
> On 9/5/19 3:17 PM, Richard Biener wrote:
> > On Tue, 16 Jul 2019, Li Jia He wrote:
> >
> >> Hi,
> >>
> >> I made some changes based on the recommendations. Would you like to
> >> help me to see it again ? Sorry, it took so long time to provide the
> >
Hi.
This patch includes implementation of fadd, faddl, daddl functions.
The patch boostraps on x86_64-linux-gnu and passes regression tests.
Thanks,
Tejas
gcc/ChangeLog:
2019-09-11 Tejas Joshi
* builtin-types.def: Define narrowing function types.
* builtins.def: Define fadd variants
On 9/11/19 2:43 PM, Richard Biener wrote:
> On Wed, 11 Sep 2019, Martin Liška wrote:
>
>> I'm sending updated version of the patch where I changed
>> from previous version:
>> - more compact matching is used (note @3 and @4):
>> (and (code1:c@3 @0 INTEGER_CST@1) (code2:c@4 @0 INTEGER_CST@2))
>>
Add a Go entry for GCC 9, for PR 91700.
Ian
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.76
diff -u -r1.76 changes.html
--- changes.html1 Sep 2019 00:28:46 - 1.
On 9/11/19 12:43 AM, Jeff Law wrote:
> On 9/10/19 1:51 PM, Bernd Edlinger wrote:
>> Hi!
>>
>> This ICE happens when compiling real_nextafter in real.c.
>> CSE sees this:
>>
>> (insn 179 178 180 11 (set (reg:SI 319)
>> (reg/v/f:SI 273 [ rD.73757 ])) "../../gcc-trunk-1/gcc/real.c":120:10
>>
On Wed, 11 Sep 2019, Bernd Edlinger wrote:
> On 9/11/19 12:43 AM, Jeff Law wrote:
> > On 9/10/19 1:51 PM, Bernd Edlinger wrote:
> >> Hi!
> >>
> >> This ICE happens when compiling real_nextafter in real.c.
> >> CSE sees this:
> >>
> >> (insn 179 178 180 11 (set (reg:SI 319)
> >> (reg/v/f:SI
On 9/11/19 9:23 AM, Richard Biener wrote:
> On Tue, 10 Sep 2019, Bernd Edlinger wrote:
>
>> Hi!
>>
>> This ICE happens when compiling real_nextafter in real.c.
>> CSE sees this:
>>
>> (insn 179 178 180 11 (set (reg:SI 319)
>> (reg/v/f:SI 273 [ rD.73757 ])) "../../gcc-trunk-1/gcc/real.c":12
On 9/11/19 2:23 PM, Richard Biener wrote:
> On Wed, 11 Sep 2019, Martin Liška wrote:
>
>> Hello.
>>
>> One another updated version of the patch.
>> Changes from the previous version:
>> - I fixed:
>> gimple *stmt1 = (gimple *) XALLOCAVEC (char, gimple_size (GIMPLE_ASSIGN,
>> 2));
>> into gimp
On Wed, 11 Sep 2019, Bernd Edlinger wrote:
> On 9/11/19 9:23 AM, Richard Biener wrote:
> > On Tue, 10 Sep 2019, Bernd Edlinger wrote:
> >
> >> Hi!
> >>
> >> This ICE happens when compiling real_nextafter in real.c.
> >> CSE sees this:
> >>
> >> (insn 179 178 180 11 (set (reg:SI 319)
> >>
On 9/11/19 3:08 PM, Richard Biener wrote:
> On Fri, 6 Sep 2019, Martin Liška wrote:
>
>> On 9/5/19 3:17 PM, Richard Biener wrote:
>>> On Tue, 16 Jul 2019, Li Jia He wrote:
>>>
Hi,
I made some changes based on the recommendations. Would you like to
help me to see it again ?
On 9/11/19 3:19 PM, Martin Liška wrote:
> On 9/11/19 2:43 PM, Richard Biener wrote:
>> On Wed, 11 Sep 2019, Martin Liška wrote:
>>
>>> I'm sending updated version of the patch where I changed
>>> from previous version:
>>> - more compact matching is used (note @3 and @4):
>>> (and (code1:c@3 @0 I
Hi.
Updated version of the patch that drops GENERIC
support in TREE codes.
Martin
>From 725f04c781c3d9cc2108b075201fc9ac7afb9a44 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 6 Sep 2019 12:47:01 +0200
Subject: [PATCH 4/5] Rewrite first part of or_comparisons_1 into match.pd.
gcc/Change
Hi.
Updated version of the patch that drops GENERIC
support in TREE codes.
Martin
>From 548ff649ae56e2f60ba4b2537d97c5bf085248d5 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 6 Sep 2019 12:59:36 +0200
Subject: [PATCH 5/5] Rewrite second part of or_comparisons_1 into match.pd.
gcc/Chang
On Tue, Sep 10, 2019 at 11:54 PM Andreas Schwab wrote:
>
> On Sep 10 2019, Ian Lance Taylor wrote:
>
> > On Mon, Sep 9, 2019 at 2:00 PM Andreas Schwab wrote:
> >>
> >> ../../../libgo/go/golang.org/x/sys/cpu/cpu.go:17:30: error: reference to
> >> undefined name ‘cacheLineSize’
> >>17 | type
This Go frontend patch by Than McIntosh suppresses type descriptor
generation for aliases.
This changes Named_object::get_backend to ignore aliases when creating
type descriptors for types, to be consistent with
Type::needs_specific_type_functions and the Specific_type_functions
traversal class.
On Tue, Sep 10, 2019 at 7:47 PM Joseph Myers wrote:
>
> Thanks, I think this is OK with a few updates to the documentation.
Thanks for looking through this, I'm glad it will be acceptable. I
will make the documentation adjustments as you suggest.
Speaking of documentation, one other thing occurr
On 9/11/19 3:55 PM, Richard Biener wrote:
> On Wed, 11 Sep 2019, Bernd Edlinger wrote:
>
>> On 9/11/19 9:23 AM, Richard Biener wrote:
>>> On Tue, 10 Sep 2019, Bernd Edlinger wrote:
>>>
Hi!
This ICE happens when compiling real_nextafter in real.c.
CSE sees this:
(insn
On September 11, 2019 4:41:10 PM GMT+02:00, Bernd Edlinger
wrote:
>On 9/11/19 3:55 PM, Richard Biener wrote:
>> On Wed, 11 Sep 2019, Bernd Edlinger wrote:
>>
>>> On 9/11/19 9:23 AM, Richard Biener wrote:
On Tue, 10 Sep 2019, Bernd Edlinger wrote:
> Hi!
>
> This ICE happens
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration
on practically any target. So set it correctly to 1 on Arm.
As a result we generate much better code for bitfields:
typedef struct
{
int x : 2, y : 8,
While code hoisting generally improves codesize, it can affect performance
negatively. Benchmarking shows it doesn't help SPEC and negatively affects
embedded benchmarks, so only enable code hoisting with -Os on Arm.
Bootstrap OK, OK for commit?
ChangeLog:
2019-09-11 Wilco Dijkstra
Ping
On Tue, 3 Sep 2019, Marc Glisse wrote:
On Fri, 2 Aug 2019, Marc Glisse wrote:
Ping
On Tue, 16 Jul 2019, Marc Glisse wrote:
Adding a C++ maintainer in Cc:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00808.html
On Wed, 10 Jul 2019, Marc Glisse wrote:
Hello,
this avoids folding __b
On 9/11/19 7:37 AM, Richard Biener wrote:
> On Wed, 11 Sep 2019, Bernd Edlinger wrote:
>
>> On 9/11/19 12:43 AM, Jeff Law wrote:
>>> On 9/10/19 1:51 PM, Bernd Edlinger wrote:
Hi!
This ICE happens when compiling real_nextafter in real.c.
CSE sees this:
(insn 179 178 18
On 9/11/19 7:49 AM, Bernd Edlinger wrote:
> On 9/11/19 9:23 AM, Richard Biener wrote:
>> On Tue, 10 Sep 2019, Bernd Edlinger wrote:
>>
>>> Hi!
>>>
>>> This ICE happens when compiling real_nextafter in real.c.
>>> CSE sees this:
>>>
>>> (insn 179 178 180 11 (set (reg:SI 319)
>>> (reg/v/f:SI
On 11/09/19 12:53, Martin Liška wrote:
> On 9/9/19 5:54 PM, Matthew Malcomson wrote:
>> On 09/09/19 11:47, Martin Liška wrote:
>>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
Hello,
>> As I understand it, `hwasan-abi=interceptor` vs `platform` is about
>> adding such MTE emulation for "ap
Hi Jeff,
Jeff wrote:
> Just to make sure I understand. Are you saying the addresses for the
> MEMs are equal or the contents of the memory location are equal.
>
> For the former the alignment has to be the same, plain and simple, even
> if GCC isn't aware the alignments have to be the same.
>
> F
> On Sep 11, 2019, at 11:48 AM, Wilco Dijkstra wrote:
>
> Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> bitfields by their declared type, which results in better codegeneration
> on practically any target. So set it correctly to 1 on Arm.
If the documentation is in
Hi Paul,
> > On Sep 11, 2019, at 11:48 AM, Wilco Dijkstra wrote:
> >
> > Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> > bitfields by their declared type, which results in better codegeneration
> > on practically any target. So set it correctly to 1 on Arm.
>
> If th
On 9/11/19 5:28 AM, Jonas Pfeil wrote:
> The Microblaze target confuses unsigned long with HOST_WIDE_INT.
>
> This works fine for many architectures, but fails on ARM (HOST_WIDE_INT is 8
> bytes, unsigned long is 4 bytes). Leading to print a uninitialized register
> instead of the desired number,
On 9/11/19 10:38 AM, Wilco Dijkstra wrote:
> Hi Jeff,
>
> Jeff wrote:
>> Just to make sure I understand. Are you saying the addresses for the
>> MEMs are equal or the contents of the memory location are equal.
>>
>> For the former the alignment has to be the same, plain and simple, even
>> if GCC
On 9/11/19 6:08 PM, Jeff Law wrote:
> On 9/11/19 7:49 AM, Bernd Edlinger wrote:
>> On 9/11/19 9:23 AM, Richard Biener wrote:
>>> On Tue, 10 Sep 2019, Bernd Edlinger wrote:
>>>
Hi!
This ICE happens when compiling real_nextafter in real.c.
CSE sees this:
(insn 179 178 18
Hi Jeff,
> We're talking about two instructions where if the first executes, then
> the second also executes. If the memory addresses are the same, then
> their alignment is the same.
>
> In your case the two instructions are on different execution paths and
> are in fact mutually exclusive.
S
Committed as obvious.
2019-09-11 Steven G. Kargl
PR fortran/91642
* io.c (gfc_match_inquire): null() cannot be in an iolength inquire
list.
2019-09-11 Steven G. Kargl
PR fortran/91642
* gfortran.dg/pr91642.f90: New test.
--
Steve
Index: gcc/fortra
On September 11, 2019 7:41:22 PM GMT+02:00, Bernd Edlinger
wrote:
>On 9/11/19 6:08 PM, Jeff Law wrote:
>> On 9/11/19 7:49 AM, Bernd Edlinger wrote:
>>> On 9/11/19 9:23 AM, Richard Biener wrote:
On Tue, 10 Sep 2019, Bernd Edlinger wrote:
> Hi!
>
> This ICE happens when compil
On Wed, Sep 11, 2019 at 9:37 AM Matthew Malcomson
wrote:
>
> On 11/09/19 12:53, Martin Liška wrote:
> > On 9/9/19 5:54 PM, Matthew Malcomson wrote:
> >> On 09/09/19 11:47, Martin Liška wrote:
> >>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> Hello,
>
> >> As I understand it, `hwasan-ab
Committed as obvious (once the problem is identified).
When simplification of an expression occurs, parenthesis can
be inserted. When simplifying a constant expression, need to
check for inserted parenthesis.
2019-09-11 Steven G. Kargl
PR fortran/91553
* simplify.c (gfc_conve
On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote:
>
> This patch annotates tests that make use of a significant a mount of
> stack space.
Ok. Future changes like this are now obvious to you and you can just maintain
them as you see fit.
On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote:
>
> This patch adds a new dg_require_effective_target procedure to the
> testsuite infrastructure: indirect_calls. This new function tells
> whether a target supports calls to non-constant call targets.
Ok. I'll let people contemplate some c
On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote:
>
> This patch makes the several effective target checks in
> target-supports.exp to be aware of eBPF targets.
Ok.
These sort of updates will now be obvious to you, now that you have gotten your
feet wet. This applies to the indirect calls
This series of patches introduces some classes and helpers for handling
multiple ABIs in the same translation unit. At the moment "ABI" maans
specifically the choice of call-clobbered registers, but I'm hoping the
structures could be used for other ABI properties in future.
The main point of the
This patch adds new structures and functions for handling
multiple ABIs in a translation unit. The structures are:
- predefined_function_abi: describes a static, predefined ABI
- function_abi: describes either a predefined ABI or a local
variant of one (e.g. taking -fipa-ra into account)
The p
This patch adds a target hook that allows targets to return
the ABI associated with a particular function type. Generally,
when multiple ABIs are in use, it must be possible to tell from
a function type and its attributes which ABI it is using.
2019-09-11 Richard Sandiford
gcc/
* tar
On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote:
>
> This patch makes many tests in gcc.dg and gcc.c-torture to be skipped
> in bpf-*-* targets. This is due to the many limitations imposed by
> eBPF
Ok.
So, see my other comments about marking and automatically skipping tests in the
indire
This patch replaces get_call_reg_set_usage with call_insn_abi,
which returns the ABI of the target of a call insn. The ABI's
full_reg_clobbers corresponds to regs_invalidated_by_call,
whereas many callers instead passed call_used_or_fixed_regs, i.e.:
(regs_invalidated_by_call | fixed_reg_set)
One of the effects of the function_abi series is to make -fipa-ra
work for partially call-clobbered registers. E.g. if a call preserves
only the low 32 bits of a register R, we handled the partial clobber
separately from -fipa-ra, and so treated the upper bits of R as
clobbered even if we knew tha
This patch replaces the rtx_insn argument to
targetm.hard_regno_call_part_clobbered with an ABI identifier, since
call insns are now just one possible way of getting an ABI handle.
This in turn allows predefined_function_abi::initialize to do the
right thing for non-default ABIs.
The horrible ?: i
choose_hard_reg_mode previously took a boolean saying whether the
mode needed to be call-preserved. This patch replaces it with an
optional ABI pointer instead, so that the function can use that
to test whether a value is call-saved.
default_dwarf_frame_reg_mode uses eh_edge_abi because that's th
All caller-save.c uses of "|= fixed_reg_set" added in a previous patch
were redundant, since the sets are later ANDed with ~fixed_reg_set.
2019-09-11 Richard Sandiford
gcc/
* caller-save.c (setup_save_areas): Remove redundant |s of
fixed_reg_set.
(save_call_clobbered_r
old_insns_match_p just tests whether two instructions are
similar enough to merge. With call_insn_abi it makes more
sense to compare the ABIs directly.
2019-09-11 Richard Sandiford
gcc/
* cfgcleanup.c (old_insns_match_p): Compare the ABIs of calls
instead of the call-clobbere
...or rather, make the use of the default ABI explicit. That seems
OK if not ideal for this heuristic.
In practical terms, the code patched here is counting GENERAL_REGS,
which are treated in the same way by all concurrent ABI variants
on AArch64. It might give bad results if used for interrupt
Like with the combine.c patch, this one keeps things simple by
invalidating values in partially-clobbered registers, rather than
trying to tell whether the value in a partially-clobbered register
is actually clobbered or not. Again, this is in principle a bug fix,
but probably never matters in pra
There shouldn't be many cases in which a useful hard register is
live across a call before RA, so we might as well keep things simple
and invalidate partially-clobbered registers here, in case the values
they hold leak into the call-clobbered part. In principle this is
a bug fix for TARGET_HARD_RE
On Sep 5, 2019, at 3:50 PM, Jose E. Marchesi wrote:
> I guess I should wait for acceptance of the remaining patches not having
> an explicit ack?
>
> This leaves the following patches that still need explicit approval:
>
> - [PATCH V6 03/11] testsuite: annotate c-torture/compile tests with
> dg
cselib_invalidate_regno is a no-op if REG_VALUES (i) is null,
so we can check that first. Then, if we know what mode the register
currently has, we can check whether it's clobbered in that mode.
Using GET_MODE (values->elt->val_rtx) to get the mode of the last
set is taken from cselib_reg_set_mod
The DF dense_invalidated_by_call and sparse_invalidated_by_call
sets are actually only used on EH edges, and so are more the set
of registers that are invalidated by a taken EH edge. Under the
new order, that means that they describe eh_edge_abi.
2019-09-11 Richard Sandiford
gcc/
* d
The code patched here is seeing whether the current function
needs to save at least part of a register before using it.
2019-09-11 Richard Sandiford
gcc/
* df-scan.c (df_get_entry_block_def_set): Use crtl->abi to test
whether the current function needs to save at least part of
This pass previously excluded rematerialisation candidates if they
clobbered a call-preserved register, on the basis that it then
wouldn't be safe to add new instances of the candidate instruction
after a call. This patch instead makes the decision on a call-by-call
basis.
The second emit_remat_i
This is another case in which we can conservatively treat partial
kills as full kills. Again this is in principle a bug fix for
TARGET_HARD_REGNO_CALL_PART_CLOBBERED targets, but in practice
it probably doesn't make a difference.
2019-09-11 Richard Sandiford
gcc/
* gcse.c: Include fu
Whatever the rights and wrongs of the way aggregate_value_p
handles call-preserved registers, it's a de facto part of the ABI,
so we shouldn't change it. The patch simply extends the current
approach to whatever call-preserved set the function happens to
be using.
2019-09-11 Richard Sandiford
The code patched here is counting how many registers the current
function would need to save in the prologue before it uses them.
The code is called per function, so using crtl is OK.
2019-09-11 Richard Sandiford
gcc/
* haifa-sched.c: Include function-abi.h.
(alloc_global_sche
On 2019-08-08 16:22, Jeff Law wrote:
> On 8/8/19 4:18 PM, Aurelien Jarno wrote:
> >
> > It is used by libgo, but it seems to be the last user.
> Ah, yes, I should have remembered libgo. And it links via
> ../../blahblah. Thanks for digging into it.
>
> So, yea, we need it. So I think the best
For -fipa-ra, IRA already keeps track of which specific registers
are call-clobbered in a region, rather than using global information.
The patch generalises this so that it tracks which ABIs are used
by calls in the region.
We can then use the new ABI descriptors to handle partially-clobbered
reg
Similar idea to the combine.c and gcse.c patches.
2019-09-11 Richard Sandiford
gcc/
* loop-iv.c: Include regs.h and function-abi.h.
(simplify_using_initial_values): Use call_insn_abi to get the
ABI of the call insn target. Conservatively assume that
partially-
This is another case in which we should conservatively treat
partial kills as full kills.
2019-09-11 Richard Sandiford
gcc/
* postreload-gcse.c: Include regs.h and function-abi.h.
(record_opr_changes): Use call_insn_abi to get the ABI of the
call insn target. Conserva
The "|= fixed_regs" in reload_combine isn't necessary, since the
set is only used to determine which values have changed (rather than,
for example, which registers are available for use).
In reload_cse_move2add we can be accurate about which registers
are still available. BLKmode indicates a cont
lra_reg has an actual_call_used_reg_set field that is only used during
inheritance. This in turn required a special lra_create_live_ranges
pass for flag_ipa_ra to set up this field. This patch instead makes
the inheritance code do its own live register tracking, using the
same ABI-mask-and-clobbe
2019-09-11 Richard Sandiford
gcc/
* recog.c: Include function-abi.h.
(peep2_find_free_register): Use crtl->abi when deciding whether
a register is free for use after RA.
Index: gcc/recog.c
===
--- gcc/recog
This is a direct replacement of an existing test for fully and
partially clobbered registers.
2019-09-11 Richard Sandiford
gcc/
* regcprop.c (copyprop_hardreg_forward_1): Use the recorded
mode of the register when deciding whether it is no longer
available after a call
1 - 100 of 120 matches
Mail list logo
