"COMPL_HARD_REG_SET (x, y)" becomes "x = ~y".
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator~): New function.
(COMPL_HARD_REG_SET): Delete.
* config/c6x/c6x.c (c6x_call_saved_register_used): Use ~ instead
of COMPL_HARD_REG_SET.
Use "x &= y" instead of "AND_HARD_REG_SET (x, y)" (or just "x & y"
if the result is a temporary).
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator&): New function.
(HARD_REG_SET::operator&): Likewise.
(AND_HARD_REG_SET): Delete.
* call
Use "x |= y" instead of "IOR_HARD_REG_SET (x, y)" (or just "x | y"
if the result is a temporary).
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator|): New function.
(HARD_REG_SET::operator|=): Likewise.
(IOR_HARD_REG_SET): Delete.
* con
Use "x |= ~y" instead of "IOR_COMPL_HARD_REG_SET (x, y)", or just
"x | ~y" if the result is a temporary.
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (IOR_COMPL_HARD_REG_SET): Delete.
* config/aarch64/cortex-a57-fma-steering.c (rename_single_chain):
Use "|~" inst
Use "x &= ~y" instead of "AND_COMPL_HARD_REG_SET (x, y)", or just
"x & ~y" if the result is a temporary. This means that we're splitting
it into two operations, but the compiler should be able to combine them
for reasonable values of FIRST_PSEUDO_REGISTER.
2019-09-09 Richard Sandiford
gcc/
Use "x == y" instead of "hard_reg_set_equal_p (x, y)".
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator==): New function.
(HARD_REG_SET::operator!=): Likewise.
(hard_reg_set_equal_p): Delete.
* cfgcleanup.c (old_insns_match_p): Use ==
This patch makes ior_hard_reg_conflicts take a const_hard_reg_set
rather than a pointer, so that it can be passed a temporary object
in later patches.
2019-09-09 Richard Sandiford
gcc/
* ira-int.h (ior_hard_reg_conflicts): Take a const_hard_reg_set
instead of a HARD_REG_SET *.
Hello.
I am using real_isfinite to check for overflow conditions. How should
I check for underflow? I have tried different ways but they
contradicted other cases to pass.
static bool
fold_const_narrow_binary (real_value *result, const real_value *arg0,
int icode, const real_value *ar
This patch switches both gcn-plugin and gcn-run to use "coarse-grained"
memory for device-resident data. I've just learned that the "kernargs"
region that we have been using is in fact host-resident.
This means that hsa_memory_copy is no longer optional, and somewhat
complicates the memory set
This patch adds a bitmap_view class that creates a read-only,
on-stack bitmap representation of an array-like object X. The main
use case is to allow HARD_REG_SETs to be used in REG_SET (i.e. bitmap)
operations.
For now it only handles constant-sized arrays, but I've tried to
define the types in
[Follows on from https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00571.html]
We currently maintain global REG_SET versions of fixed_reg_set
and regs_invalidated_by_call. With bitmap_view, we can instead
operate directly on the underlying HARD_REG_SETs, avoiding the
need to keep the two pieces of da
On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > With patch, the only following FAIL remains for aarch64-sve.exp:
> > FAIL: gcc.target/aarch64/sve/cond_unary_2.c -march=armv8.2-a+sve
> > scan-assembler-times \\tmovprfx\\t 6
> > which now contains 14.
> > S
Currently arm_legitimize_address doesn't handle Thumb-2 at all, resulting in
inefficient code. Since Thumb-2 supports similar address offsets use the Arm
legitimization code for Thumb-2 to get significant codesize and performance
gains. SPECINT2006 shows 0.4% gain on Cortex-A57, while SPECFP impr
On 9/9/19 5:38 AM, Jonathan Wakely wrote:
On 06/09/19 18:08 -0400, Ed Smith-Rowland via libstdc++ wrote:
As the title says.
was (correctly) delivered without comparison ops. so we chould
check off p1085.
Indeed, thanks!
This includes the status updates for constexpr lib diffs posted
previ
Setting HONOR_REG_ALLOC_ORDER improves codesize with -Os, however it generates
slower and larger code with -O2 and higher. So only set it when optimizing for
size. On Cortex-A57 this improves SPECINT2006 by 0.15% and SPECFP2006 by 0.25%
while reducing codesize.
Bootstrap OK, OK for commit?
Chan
ping
Currently the Arm backend selects the alternative sched pressure algorithm.
The issue is that this doesn't take register pressure into account, and so
it causes significant additional spilling on Arm where there are only 14
allocatable registers. SPEC2006 shows si
ping
We currently use default mid-end expanders for logical DImode operations.
These split operations without first splitting off complex immediates or
memory operands. The resulting expansions are non-optimal and allow for
fewer LDRD/STRD opportunities. So add back explicit expanders wh
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
fo
ping
Remove various MULS/MLAS patterns which are enabled when optimizing for
size. However the codesize gain from these patterns is so minimal that
there is no point in keeping them.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wilco Dijkstra
* config/a
ping
Cleanup the 32-bit multiply patterns. Merge the pre-Armv6 with the Armv6
patterns, remove useless alternatives and order the accumulator operands
to prefer MLA Ra, Rb, Rc, Ra whenever feasible.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wilco Dijkstra
ping
Cleanup the various highpart multiply patterns using iterators.
As a result the signed and unsigned variants and the pre-Armv6
multiply operand constraints are all handled in a single pattern
and simple expander.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wil
ping
Cleanup 64-bit multiplies. Combine the expanders using iterators.
Merge the signed/unsigned multiplies as well as the pre-Armv6 and Armv6
variants. Split DImode operands early into parallel sets inside the
MULL/MLAL instructions - this improves register allocation and avoids
subreg
On 9/9/19 5:41 AM, Jonathan Wakely wrote:
On 05/09/19 15:45 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is a patch to the libstdc++ docs re constexpr additions. They
reflect the latest macro assignments AFAICT.
Constexpr interator reqs are implemented in 9.1, the rest for 10.1.
Ok?
Sho
On 9/9/19 9:53 AM, Richard Sandiford wrote:
> We have two styles of HARD_REG_SET: a single integer based on
> HOST_WIDEST_FAST_INT (used when FIRST_PSEUDO_REGISTER is small enough)
> or an array of integers. One of the nice properties of this arrangement
> is that:
>
> void foo (const HARD_REG_
On 9/9/19 9:58 AM, Richard Sandiford wrote:
> This patch replaces "COPY_HARD_REG_SET (x, y)" with "x = y".
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (COPY_HARD_REG_SET): Delete.
> * caller-save.c (save_call_clobbered_regs): Use assignment instead
> of CO
On 9/9/19 9:59 AM, Richard Sandiford wrote:
> "COMPL_HARD_REG_SET (x, y)" becomes "x = ~y".
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator~): New function.
> (COMPL_HARD_REG_SET): Delete.
> * config/c6x/c6x.c (c6x_call_saved_register_u
On 9/9/19 9:59 AM, Richard Sandiford wrote:
> Use "x &= y" instead of "AND_HARD_REG_SET (x, y)" (or just "x & y"
> if the result is a temporary).
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator&): New function.
> (HARD_REG_SET::operator&): Li
On 9/9/19 10:00 AM, Richard Sandiford wrote:
> Use "x |= y" instead of "IOR_HARD_REG_SET (x, y)" (or just "x | y"
> if the result is a temporary).
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator|): New function.
> (HARD_REG_SET::operator|=):
On 9/9/19 10:01 AM, Richard Sandiford wrote:
> Use "x &= ~y" instead of "AND_COMPL_HARD_REG_SET (x, y)", or just
> "x & ~y" if the result is a temporary. This means that we're splitting
> it into two operations, but the compiler should be able to combine them
> for reasonable values of FIRST_PSEUD
On 9/9/19 10:01 AM, Richard Sandiford wrote:
> Use "x |= ~y" instead of "IOR_COMPL_HARD_REG_SET (x, y)", or just
> "x | ~y" if the result is a temporary.
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (IOR_COMPL_HARD_REG_SET): Delete.
> * config/aarch64/cortex-a57-
On 9/9/19 10:02 AM, Richard Sandiford wrote:
> Use "x == y" instead of "hard_reg_set_equal_p (x, y)".
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator==): New function.
> (HARD_REG_SET::operator!=): Likewise.
> (hard_reg_set_equal_p): De
On 9/9/19 10:02 AM, Richard Sandiford wrote:
> This patch makes ior_hard_reg_conflicts take a const_hard_reg_set
> rather than a pointer, so that it can be passed a temporary object
> in later patches.
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * ira-int.h (ior_hard_reg_conflicts): T
On 9/9/19 10:32 AM, Richard Sandiford wrote:
> This patch adds a bitmap_view class that creates a read-only,
> on-stack bitmap representation of an array-like object X. The main
> use case is to allow HARD_REG_SETs to be used in REG_SET (i.e. bitmap)
> operations.
>
> For now it only handles cons
On 9/9/19 10:37 AM, Richard Sandiford wrote:
> [Follows on from https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00571.html]
>
> We currently maintain global REG_SET versions of fixed_reg_set
> and regs_invalidated_by_call. With bitmap_view, we can instead
> operate directly on the underlying HARD_R
I never got around to updating these testcases after the combine hardreg
changes (and more). This patch does not fix all failures, just the simple
ones that are obvious improvements. The rest need more work.
Committing to trunk.
Segher
2019-09-09 Segher Boessenkool
gcc/testsuite/
On 9/9/19 5:33 AM, Richard Sandiford wrote:
> I have a series of patches that (as a side effect) makes all rtl
> passes use the information collected by -fipa-ra. This showed up a
> latent bug in the liveness tracking in regrename.c, which doesn't take
> CALL_INSN_FUNCTION_USAGE into account when
On 9/6/19 5:26 PM, Martin Sebor wrote:
> Just a heads up that I tested the patch with Glibc and the kernel.
> It exposes some of the same "abuses" of (near) zero-length arrays
> as the most recent improvement in this area. In glibc, it
> complains about code in fileops.c, iofwide.c, libc-tls.c, an
Jeff Law writes:
> On 9/9/19 5:33 AM, Richard Sandiford wrote:
>> I have a series of patches that (as a side effect) makes all rtl
>> passes use the information collected by -fipa-ra. This showed up a
>> latent bug in the liveness tracking in regrename.c, which doesn't take
>> CALL_INSN_FUNCTION_
Jeff Law writes:
> On 9/9/19 9:53 AM, Richard Sandiford wrote:
>> We have two styles of HARD_REG_SET: a single integer based on
>> HOST_WIDEST_FAST_INT (used when FIRST_PSEUDO_REGISTER is small enough)
>> or an array of integers. One of the nice properties of this arrangement
>> is that:
>>
>>
On September 9, 2019 4:17:20 PM GMT+02:00, Ulrich Weigand
wrote:
>Richard Biener wrote:
>> On Fri, Sep 6, 2019 at 3:00 PM Ulrich Weigand
>wrote:
>> > But as far as I can see, for *atomic* operations at least, we do
>make
>> > that assumption. The x86 back-end for example just assumes that
>any
Hi
This patch improves stl_algobase.h
copy/copy_backward/fill/fill_n/equal implementations. The improvements are:
- activation of algo specialization for __gnu_debug::_Safe_iterator (w/o
_GLIBCXX_DEBUG mode)
- activation of algo specialization for _Deque_iterator even if mixed
with ano
On 9/4/19 12:16 PM, Rafael Tsuha wrote:
> Hi, Jeff
>
> Em seg, 29 de abr de 2019 às 18:22, Jeff Law escreveu:
>>
>> On 1/22/19 12:31 PM, Rafael Tsuha wrote:
>>> This patch simplifies the expression sinh (x) / cosh (x) to tanh (x).
>>> This rule is mathematically valid.
>>>
>>> There's a slight di
On 9/6/19 12:02 AM, Bernd Edlinger wrote:
> Hi,
>
>
> as discussed already I propose this little refactoring as a follow-up
> which is not supposed to be doing any change to the code generation.
>
> I tried to get the description of ALT_RTL right, since it changed
> quite a lot recently what thi
On 09/09/19 13:04 -0400, Ed Smith-Rowland wrote:
On 9/9/19 5:38 AM, Jonathan Wakely wrote:
On 06/09/19 18:08 -0400, Ed Smith-Rowland via libstdc++ wrote:
As the title says.
was (correctly) delivered without comparison ops. so we
chould check off p1085.
Indeed, thanks!
This includes the st
On 9/6/19 7:36 AM, Martin Liška wrote:
> Hi.
>
> I've been working on transition of cond expressions to match.pd.
> With my changes I noticed there's one wrong pattern that leads to:
>
> Transforming _6 > _7 & _6 < _7 into 0
> ...
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/vector-c
Hi,
thank you for looking into it.
On Fri, Sep 06, 2019 at 12:23:40PM +0200, Richard Biener wrote:
> On Thu, Sep 5, 2019 at 5:35 PM Dmitrij Pochepko
> wrote:
> >
> > This patch adds matching for Hamming weight (popcount) implementation. The
> > following sources:
> >
> > int
> > foo64 (unsigned
On 9/6/19 4:58 AM, Graham Markall wrote:
> This patch is an RFC to invite comments as to whether the approach
> to solving the problem is a suitable one for upstream GCC, or whether
> there are alternative approaches that would be recommended.
>
> Motivation
> --
>
> We have observed that
Hi,
thank you for looking into it.
On Fri, Sep 06, 2019 at 12:13:34PM +, Wilco Dijkstra wrote:
> Hi,
>
> +(simplify
> + (convert
> +(rshift
> + (mult
>
> > is the outer convert really necessary? That is, if we change
> > the simplification result to
>
> Indeed that should be "co
On 9/9/19 8:53 PM, Jeff Law wrote:
On 9/6/19 7:36 AM, Martin Liška wrote:
Hi.
I've been working on transition of cond expressions to match.pd.
With my changes I noticed there's one wrong pattern that leads to:
Transforming _6 > _7 & _6 < _7 into 0
...
/home/marxin/Programming/gcc/gcc/testsuite
Hi all.
Please take a look at v2 (attached).
I changed patch according to review comments. The same testing was performed
again.
Thanks,
Dmitrij
On Thu, Sep 05, 2019 at 06:34:49PM +0300, Dmitrij Pochepko wrote:
> This patch adds matching for Hamming weight (popcount) implementation. The
> foll
On Thu, 22 Aug 2019 at 00:05, Prathamesh Kulkarni
wrote:
>
> On Mon, 19 Aug 2019 at 22:14, James Greenhalgh
> wrote:
> >
> > On Thu, Aug 15, 2019 at 02:11:25PM +0100, Prathamesh Kulkarni wrote:
> > > On Thu, 8 Aug 2019 at 11:22, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Thu, 1 Aug 201
We forgot to ever traverse types of constant expressions in the Go
frontend. This rarely makes a difference--evidently, since nobody
noticed--but it does matter when we inline constant expressions: we
need to ensure that the type is visible to the importing code. This
patch fixes the omissions.
In the Go frontend, for the main package, we add an implicit import of
the runtime package, to ensure that it is initialized. That import
used the predeclared location, which caused various tests, notably
Named_type::is_builtin, to treat these imported names as builtin.
Start using a real location
On 21/08/19 23:36 -0400, Ed Smith-Rowland via libstdc++ wrote:
On 8/20/19 6:14 PM, Jonathan Wakely wrote:
On 16/08/19 22:39 -0400, Ed Smith-Rowland via libstdc++ wrote:
The latest draft and I guess the above paper changed the macro
names for the C++20 constexpr lib featues.
__cpp_lib_constexp
On Sat, Sep 7, 2019 at 8:20 AM Andreas Schwab wrote:
>
> On Sep 07 2019, Bernd Edlinger wrote:
>
> > Hi Ian,
> >
> >> gotools:
> >>
> >> 2019-09-06 Ian Lance Taylor
> >>
> >> * Makefile.am (check-carchive-test): Just run "go test", not "go
> >> test carchive_test.go".
> >> * Makefile.in: Regen
On 8/26/19 3:00 AM, Richard Biener wrote:
> On Fri, Aug 23, 2019 at 9:19 PM Jeff Law wrote:
>>
>> On 8/22/19 4:46 AM, Richard Biener wrote:
> Also you seem to use this info to constrain optimization when you
> might remember that types of addresses do not carry such information...
> Th
On Fri, Sep 06, 2019 at 07:50:51AM -0500, Segher Boessenkool wrote:
> On Thu, Sep 05, 2019 at 08:18:02PM -0400, Michael Meissner wrote:
> > On Thu, Aug 29, 2019 at 04:32:07PM -0500, Segher Boessenkool wrote:
> > > This is not just for reload anymore, so please don't name it that.
> > > Renaming
>
On Fri, Sep 06, 2019 at 07:09:45AM -0500, Segher Boessenkool wrote:
> On Wed, Sep 04, 2019 at 01:26:27PM -0400, Michael Meissner wrote:
>
> [snip]
>
> > So to keep other passes from 'improving' things, I opted to do the pass as
> > the
> > last pass before final.
>
> If the problem is that you
On Mon, 9 Sep 2019 at 22:06, Prathamesh Kulkarni
wrote:
>
> On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > With patch, the only following FAIL remains for aarch64-sve.exp:
> > > FAIL: gcc.target/aarch64/sve/cond_unary_2.c -march=armv8.2-a+sve
>
On 9/7/19 3:37 PM, Marek Polacek wrote:
* parser.c (CP_PARSER_FLAGS_NO_DELAY_NOEXCEPT): New parser flag.
Is it feasible to reverse this, and specifically delay parsing of
noexcept-specifications on member function declarations? When else
would we want it?
Jason
On Mon, Sep 09, 2019 at 04:32:39PM -0400, Michael Meissner wrote:
> On Fri, Sep 06, 2019 at 07:09:45AM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 04, 2019 at 01:26:27PM -0400, Michael Meissner wrote:
> >
> > [snip]
> >
> > > So to keep other passes from 'improving' things, I opted to do the
On 9/8/19 11:47 AM, Marek Polacek wrote:
[dcl.type.auto.deduct]/5 "If the placeholder-type-specifier is of the
form type-constraintopt decltype(auto), T shall be the placeholder alone."
So, only plain decltype(auto) is allowed. But we aren't diagnosing it in
function declarations, because do_au
../../../libgo/go/golang.org/x/sys/cpu/cpu.go:17:30: error: reference to
undefined name ‘cacheLineSize’
17 | type CacheLinePad struct{ _ [cacheLineSize]byte }
| ^
../../../libgo/go/golang.org/x/sys/cpu/cpu_linux.go:56:2: error: reference to
undefined name ‘do
On 9/2/19 9:28 AM, Paolo Carlini wrote:
Hi,
all should be more or less straightforward. I also propose to use an
additional range for that error message about constinit && constexpr
mentioned to Marek a few days ago. Tested x86_64-linux.
Thanks, Paolo.
/
OK.
Jaso
On Mon, 9 Sep 2019, Jakub Jelinek wrote:
> > "IgnoreWarn" reads as "ignore the warning".
> >
> > If we want it named as two things, can we just make it two things?
> > "Ignore WarnDeleted" or something. Which also says what it is warning
> > about.
>
> Or WarnRemoved. Both work for me, but ult
On Mon, 9 Sep 2019, Tejas Joshi wrote:
> Hello.
> I am using real_isfinite to check for overflow conditions. How should
> I check for underflow? I have tried different ways but they
> contradicted other cases to pass.
I think the right check for underflow is: *before* calling
exact_real_truncate
On Mon, Sep 09, 2019 at 03:56:52PM -0500, Segher Boessenkool wrote:
> On Mon, Sep 09, 2019 at 04:32:39PM -0400, Michael Meissner wrote:
> > On Fri, Sep 06, 2019 at 07:09:45AM -0500, Segher Boessenkool wrote:
> > > On Wed, Sep 04, 2019 at 01:26:27PM -0400, Michael Meissner wrote:
> > >
> > > [snip]
On Sat, Sep 7, 2019 at 5:03 AM Andreas Schwab wrote:
>
> This has dropped support for riscv64:
Thanks, and sorry. The gccgo-local changes were lost when the files
moved. I restored them as follows. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gc
On Mon, Sep 09, 2019 at 04:59:57PM -0400, Jason Merrill wrote:
> Maybe check this in one place, after splice_late_return_type?
That works! So like this?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-09-09 Marek Polacek
PR c++/84374 - diagnose invalid uses of decltype(au
+Peter Collingbourne +Evgeniy Stepanov (the main developers of HWASAN
in LLVM, FYI)
Please note that Peter has recently implemented support for globals in
LLVM's HWASAN.
--kcc
On Mon, Sep 9, 2019 at 8:55 AM Matthew Malcomson
wrote:
>
> On 09/09/19 11:47, Martin Liška wrote:
> > On 9/6/19 4:46 P
On 9/9/19 7:03 PM, Marek Polacek wrote:
On Mon, Sep 09, 2019 at 04:59:57PM -0400, Jason Merrill wrote:
Maybe check this in one place, after splice_late_return_type?
That works! So like this?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK, thanks.
Jason
This patch to the Go frontend permits inlining constant expressions
and expression statements. This relatively minor change increases the
number of inlinable functions/methods in the standard library from 983
to 2179. In particular it permits inlining math/bits/RotateLeftNN.
This restores the spe
This libgo patch changes the go tool to look for a tool build ID
before hashing the entire file It also fixes the key used to store
the ID. This is a significant speedup in go tool run time.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofro
101 - 173 of 173 matches
Mail list logo
