Hi,
we recently hit a problem where fwprop would not propagate a memory
address into an insn because our backend (s390) tells it that the
address_cost ()s for an address with index are higher than for one
without. Subsequently, should_replace_address () returns false and no
propagation is performe
This fixes handle_packed_attribute creating a type variant which differs
in TYPE_PACKED. This cannot be generally allowed since TYPE_PACKED
affects layout and layout is shared between variants.
For the testcase in question the attribute itself is later ignored
but TYPE_PACKED is still applied w
On 09/07/18 22:44, Martin Sebor wrote:
> On 07/09/2018 06:40 AM, Richard Biener wrote:
>> On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
>>>
>>> On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
>
> GCC folds accesses to members of c
Hi Kyrill,
On 07/10/2018 10:55 AM, Kyrill Tkachov wrote:
Hi Jackson,
On 10/07/18 09:37, Jackson Woodruff wrote:
Hi all,
This patch removes some duplicated code. Since this method deals with
four loads or stores, there is a lot of duplicated code that can easily
be replaced with smaller loop
Hi there,
The current RTL patterns for widening addition and subtraction
instructions in
aarch64-simd.md use the code iterator attribute to make their
definition more compact.
This approach means that the `minus` and `plus` cases have their operands in
the same order, which causes problems in
On 12/06/18 11:03, Tom de Vries wrote:
> [ Fixed ENOPATCH ]
>
> On Tue, Jun 12, 2018 at 11:57:13AM +0200, Tom de Vries wrote:
>> [ was: Re: [MAINTAINERS, committed] Remove redundant write-after-approval
>> entries ]
>>
>> On Tue, Jun 12, 2018 at 10:26:31AM +0200, Martin Liška wrote:
>>> Hi.
>>>
>>
This patch implements a -fsave-optimization-record option, which
leads to a JSON file being written out, recording the dump_* calls
made (via the optinfo infrastructure in the previous patch).
The patch includes a minimal version of the JSON patch I posted last
year, with just enough support neede
Changes relative to v4:
* eliminated optinfo subclasses as discussed
* eliminated optinfo-internal.h, moving what remained into optinfo.h
* added support for dump_gimple_expr_loc and dump_gimple_expr
* more selftests
This patch implements a way to consolidate dump_* calls into
optinfo objects, as
Hi All,
The patch series will allow AArch64 to use 64k guard sizes correctly and
improves the code quality.
It also enables a reduction of the overhead in code size over the current GCC 8
implementation.
Using 64k guard sizes results in a reduction in overhead compared to the 4k
guard size.
Th
Hi All,
This patch cleans up the testsuite when a run is done with stack clash
protection turned on.
Concretely this switches off -fstack-clash-protection for a couple of tests:
* sve: We don't yet support stack-clash-protection and sve, so for now turn
these off.
* assembler scan: some tests a
Hi All,
This patch implements the use of the stack clash mitigation for aarch64.
In Aarch64 we expect both the probing interval and the guard size to be 64KB
and we enforce them to always be equal.
We also probe up by 1024 bytes in the general case when a probe is required.
AArch64 has the follo
Hi All,
This patch defines a configure option to allow the setting of the default
guard size via configure flags when building the target.
The new flag is:
* --with-stack-clash-protection-guard-size=
The value of configured based params are set very early on and allow the
target to validate or
Hi All,
This patch adds a hook to tell the mid-end about the probing requirements of the
target. On AArch64 we allow a specific range for which no probing needs to
be done. This same range is also the amount that will have to be probed up when
a probe is needed after dropping the stack.
Definin
On Tue, Jul 10, 2018 at 11:46:54AM +0200, Richard Biener wrote:
> On Tue, 10 Jul 2018, Trevor Saunders wrote:
>
> > On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote:
> > >
> > > The following makes the hash-map iterator dereference return a pair > > Value&> rather than a copy of Val
Hi All,
This patch builds on a previous patch to pass param options down from configure
by adding more expansive validation and correctness checks.
These are set very early on and allow the target to validate or reject the
values as they see fit.
To do this compiler_param has been extended to ho
Hi All,
This patch defines the default parameters and validation for the aarch64
stack clash probing interval and guard sizes. It cleans up the previous
implementation and insures that at no point the invalidate arguments are
present in the pipeline for AArch64. Currently they are only corrected
Hi All,
This patch adds the ability for backends to add custom constrains to the param
values by defining a new hook option_validate_param.
This hook is invoked on every set_param_value which allows the back-end to
ensure that the parameters are always within it's desired state.
Bootstrapped Reg
Hi Andrew,
On 11 July 2018 at 15:43, Andrew Pinski wrote:
> On Tue, Jul 10, 2018 at 6:35 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Andrew,
>>
>> On 11 July 2018 at 11:19, Andrew Pinski wrote:
>> > On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
>> > wrote:
>> >>
>> >> On 10 July 2018
Hi All,
This patch adds a requirement that the number of outgoing arguments for a
function is at least 8 bytes when using stack-clash protection.
By using this condition we can avoid a check in the alloca code and so have
smaller and simpler code there.
A simplified version of the AArch64 stack
Hi All,
This patch enforces that the default guard size for stack-clash protection for
AArch64 be 64KB unless the user has overriden it via configure in which case
the user value is used as long as that value is within the valid range.
It also does some basic validation to ensure that the guard s
On Wed, Jul 11, 2018 at 1:26 PM Kugan Vivekanandarajah
wrote:
>
> Hi Andrew,
>
> On 11 July 2018 at 15:43, Andrew Pinski wrote:
> > On Tue, Jul 10, 2018 at 6:35 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi Andrew,
> >>
> >> On 11 July 2018 at 11:19, Andrew Pinski wrote:
> >> > On Tue, Jul
On Tue, Jul 10, 2018 at 12:14 PM Aldy Hernandez wrote:
>
> Ho hum, more abstractions.
>
> No change in functionality.
>
> OK for trunk?
OK. Bonus points for finding the copy I vaguely remember exists somewhere...
Richard.
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
>
> Hmmm, I think we can do better, and since this hasn't been reviewed yet,
> I don't think anyone will mind the adjustment to the patch ;-).
>
> I really hate int_const_binop_SOME_RANDOM_NUMBER. We should abstract
> them into properly named
The following fixes PR86452 by using scope_die_for which correctly
deals with -g1 in not creating (new) DIEs for namespaces. With
a larger LTO testcase we run into this with a namespace DIE not
readily available but I'm not sure the issue isn't latent with
non-LTO.
The original code was added w
On Tue, Jul 10, 2018 at 09:18:18AM +0200, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
I found two small issues and one big issue (results being declare target)
which break the test if using non-shared memory offloading.
This should fix it, tes
On 11/07/18 11:00, Andre Vieira (lists) wrote:
> On 09/07/18 22:44, Martin Sebor wrote:
>> On 07/09/2018 06:40 AM, Richard Biener wrote:
>>> On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
On 07/06/2018 09:52 AM, Richard Biener wrote:
> On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor
On Wed, Jul 11, 2018 at 11:55:32AM +0200, Richard Biener wrote:
>
> This fixes handle_packed_attribute creating a type variant which differs
> in TYPE_PACKED. This cannot be generally allowed since TYPE_PACKED
> affects layout and layout is shared between variants.
>
> For the testcase in questi
On 07/11/2018 07:50 AM, Andre Vieira (lists) wrote:
On 11/07/18 11:00, Andre Vieira (lists) wrote:
On 09/07/18 22:44, Martin Sebor wrote:
On 07/09/2018 06:40 AM, Richard Biener wrote:
On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, J
The Go spec says that when an index expression appears on the left
hand side of an assignment, the operands should be evaluated. The
gofrontend code was assuming that that only referred to the index
operand. But discussion of https://golang.org/issue/23188 has
clarified that this means both the sli
As part of the transition from the original support for named FPUs to
general FPU properties I defined an entry in the CPU definitions in
arm-cpus.in to use a named FPU. However, that has now outlived its
usefulness and increasingly we are likely to find that newer cores do
not fit the legacy FPU
Hi,
the following patch increases the default function alignment to 16
bytes. This helps get rid of some unwanted performance effects.
I'm unsure whether or when it's necessary to implement
OVERRIDE_OPTIONS_AFTER_CHANGE.
Apparently ia64 did it to set flags that are reset when using
__attribute__
David Malcolm writes:
> On Mon, 2018-06-25 at 11:10 +0200, Richard Biener wrote:
>> On Fri, 22 Jun 2018, David Malcolm wrote:
>>
>> > NightStrike and I were chatting on IRC last week about
>> > issues with trying to vectorize the following code:
>> >
>> > #include
>> > std::size_t f(std::vector
On 07/08/2018 06:03 PM, Paul Koning wrote:
> In doing CCmode work I was confused how define_subst handles cases where the
> same argument appears more than once. The attached clarifies this.
>
> Ok for trunk?
>
> paul
>
> ChangeLog:
>
> 2018-07-08 Paul Koning
>
> * doc/md.texi
On 07/10/2018 05:14 AM, Aldy Hernandez wrote:
> I believe I missed this companion patch when I submitted...
>
> Subject: jump threading multiple paths that start from the same BB
>
> The attached patch changes thread_through_all_blocks to allow threads
> that start from the same basic block as
On 07/10/2018 10:50 AM, Paul Koning wrote:
> "mode" is documented as a variable attribute but not as a type attribute.
> This fixes that omission. I simply copied the other text, it seemed suitable
> as it stands.
>
> The attributes are normally listed in alphabetical order but "mode" was out
Hi Sudi,
Thanks for the review.
On 07/10/2018 10:56 AM, Sudakshina wrote:
Hi Jackson
- if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
+ if (!MEM_P (mem[1]) || aarch64_mem_pair_operand (mem[1], mode))
mem_1 == mem[1]?
Oops, yes... That should be mem[0].
return false;
Hi Sudi,
On 07/10/2018 02:29 PM, Sudakshina Das wrote:
Hi Jackson
On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
Hi all,
This patch resolves PR86014. It does so by noticing that the last
load may clobber the address register without issue (regardless of
where it exists in the f
On 07/11/2018 08:52 AM, Richard Biener wrote:
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
Hmmm, I think we can do better, and since this hasn't been reviewed yet,
I don't think anyone will mind the adjustment to the patch ;-).
I really hate int_const_binop_SOME_RANDOM_NUMBER. We
Richard Biener writes:
> On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
>>
>> Hmmm, I think we can do better, and since this hasn't been reviewed yet,
>> I don't think anyone will mind the adjustment to the patch ;-).
>>
>> I really hate int_const_binop_SOME_RANDOM_NUMBER. We should abstr
On 07/11/2018 05:20 AM, Tamar Christina wrote:
> Hi All,
>
> This patch implements the use of the stack clash mitigation for aarch64.
> In Aarch64 we expect both the probing interval and the guard size to be 64KB
> and we enforce them to always be equal.
>
> We also probe up by 1024 bytes in the
Hi,
It was recently brought to our attention that the existing emmintrin.h
header, which was believed to be feature-complete for SSE2 support, is
actually missing four logical-op interfaces:
_mm_and_si128
_mm_andnot_si128
_mm_or_si128
_mm_xor_si128
This patch provides those with the obvious
On 07/11/2018 05:20 AM, Tamar Christina wrote:
> Hi All,
>
> This patch implements the use of the stack clash mitigation for aarch64.
> In Aarch64 we expect both the probing interval and the guard size to be 64KB
> and we enforce them to always be equal.
>
> We also probe up by 1024 bytes in the
Aldy Hernandez writes:
> On 07/11/2018 08:52 AM, Richard Biener wrote:
>> On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
>>>
>>> Hmmm, I think we can do better, and since this hasn't been reviewed yet,
>>> I don't think anyone will mind the adjustment to the patch ;-).
>>>
>>> I really hat
On Wed, 2018-07-11 at 16:56 +0100, Richard Sandiford wrote:
> David Malcolm writes:
> > On Mon, 2018-06-25 at 11:10 +0200, Richard Biener wrote:
> > > On Fri, 22 Jun 2018, David Malcolm wrote:
> > >
> > > > NightStrike and I were chatting on IRC last week about
> > > > issues with trying to vecto
On 07/11/2018 05:21 AM, Tamar Christina wrote:
> Hi All,
>
> This patch adds a hook to tell the mid-end about the probing requirements of
> the
> target. On AArch64 we allow a specific range for which no probing needs to
> be done. This same range is also the amount that will have to be probed
On 07/02/2018 07:14 AM, Tom de Vries wrote:
> On 06/21/2018 03:58 PM, Cesar Philippidis wrote:
>> On 06/20/2018 03:15 PM, Tom de Vries wrote:
>>> On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
Now it follows the formula contained in
the "CUDA Occupancy Calculator" spreadsheet that's dis
On 07/11/2018 05:22 AM, Tamar Christina wrote:
> Hi All,
>
> This patch defines a configure option to allow the setting of the default
> guard size via configure flags when building the target.
>
> The new flag is:
>
> * --with-stack-clash-protection-guard-size=
>
> The value of configured bas
On 07/11/2018 05:24 AM, Tamar Christina wrote:
> Hi All,
>
> This patch adds the ability for backends to add custom constrains to the param
> values by defining a new hook option_validate_param.
>
> This hook is invoked on every set_param_value which allows the back-end to
> ensure that the param
On 07/11/2018 05:24 AM, Tamar Christina wrote:
> Hi All,
>
> This patch builds on a previous patch to pass param options down from
> configure
> by adding more expansive validation and correctness checks.
>
> These are set very early on and allow the target to validate or reject the
> values as
On 07/07/2018 02:15 AM, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Jul 06, 2018 at 12:47:07PM +0200, Jakub Jelinek wrote:
>> On Thu, Jul 05, 2018 at 11:57:26PM +0300, Grazvydas Ignotas wrote:
>>> I think it would be more efficient if you took care of it. I won't
>>> have time for at least a few days a
I have a reload/register allocation question and possible patch. While
working on the Aarch64 SIMD ABI[1] I ran into a problem where GCC was
saving and restoring registers that it did not need to. I tracked it
down to lra-constraints.c and its use of
targetm.hard_regno_call_part_clobbered on inst
On 07/10/2018 10:43 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 16:42, Jeff Law wrote:
>> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
>>> On 10/07/18 00:13, Jeff Law wrote:
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>
> To address all of the above, these patches
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
> This patch is the main part of the speculation tracking code. It adds
> a new target-specific pass that is run just before the final branch
> reorg pass (so that it can clean up any new edge insertions we make).
> The pass is only run with -mtrack-
Hi all,
after the dust of the heated discussion around this PR has settled a
bit, here is another attempt to implement at least some basic warnings
about compiler-dependent behavior concerning the short-circuiting of
logical expressions.
As a reminder (and recap of the previous discussion), the F
On 07/11/2018 12:24 PM, Trevor Saunders wrote:
> However if we went that route we should prevent use of the
> assignment operator by declaring one explicitly and making it private but
> then not implementing it, so it at least fails to link and with some
> macros you can actually tell the compiler
On 07/11/2018 02:07 PM, Steve Ellcey wrote:
> I have a reload/register allocation question and possible patch. While
> working on the Aarch64 SIMD ABI[1] I ran into a problem where GCC was
> saving and restoring registers that it did not need to. I tracked it
> down to lra-constraints.c and its u
Hi, This is the 3rd version of the patch for the last part of PR78809.
the major change in this version is to address the following concerns raised by
Martin:
> One of the basic design principles that I myself have
> accidentally violated in the past is that warning options
> should not impact
The attached change set adjusts the attribute exclusion code
to detect and reject incompatible attributes before attribute
handlers are called to have a chance to make changes despite
the exclusions. The handlers are not run when a conflict is
found.
Tested on x86_64-linux. I expected the fallo
Hi!
The following testcase is a similar issue to PR84503 and the fix is similar,
because coalesce_immediate_stores temporarily sorts the stores on ascending
bitpos and if stores are merged, the merged store is emitted in the location
of the latest of the stores, we need to verify that there is no
On 11/07/18 21:46, Jeff Law wrote:
> On 07/10/2018 10:43 AM, Richard Earnshaw (lists) wrote:
>> On 10/07/18 16:42, Jeff Law wrote:
>>> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
On 10/07/18 00:13, Jeff Law wrote:
> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>
>>
Hi!
On Mon, Jul 09, 2018 at 02:08:37PM -0500, Will Schmidt wrote:
> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin):
> Add support for gimple-folding of vec_pack() and vec_unpack()
> intrinsics.
> +case ALTIVEC_BUILTIN_VUPKHPX:
> +case ALTIVEC_BUILTIN_VUPKLPX:
> +
Hi Will,
On Mon, Jul 09, 2018 at 02:08:49PM -0500, Will Schmidt wrote:
> * gcc.target/powerpc/fold-vec-unpack-char.c: New.
> * gcc.target/powerpc/fold-vec-unpack-float.c: New.
> * gcc.target/powerpc/fold-vec-unpack-int.c: New.
> * gcc.target/powerpc/fold-vec-unpack-pixel.c
On Mon, Jul 09, 2018 at 02:08:55PM -0500, Will Schmidt wrote:
>Add support for early gimple folding of vec_perm. Testcases are already
> in-tree as
> gcc.target/powerpc/fold-vec-perm-*.c
>
> OK for trunk?
Looks fine to me. Okay if no one else complains :-)
Segher
> * gcc/config/
Ping. Last patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00735.html
This patch removes the obsolete documentation for
decrement_and_branch_until_zero. It also adds detail to the description for
doloop_end. In particular, it describes the required form of the conditional
branch part of the pattern.
Ok for trunk?
paul
ChangeLog:
2018-07-11 Paul Koni
PR c++/84993 identifies a problem with our suggestions for
misspelled member names in the C++ FE for the case where the
member is private.
For example, given:
class foo
{
public:
double get_ratio() const { return m_ratio; }
private:
double m_ratio;
};
void test(foo *ptr)
{
if (ptr->ratio
A type alias and its underlying type are identical. This patch to the
Go frontend by Cherry Zhang builds a single backend type for them.
Previously we build two backend types, which sometimes confuse the
backend's type system.
Also don't include type aliases into the list of named type
declaratio
Hi,
this is a heads-up that configuring with --enable-maintainer-mode
currently breaks bootstrap; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
for details.
Running configure with --enable-maintainer-mode --disable-werror
allows bootstrap to proceed until the underlying issue is fixed
Jeff Law writes:
> On 07/11/2018 02:07 PM, Steve Ellcey wrote:
>> I have a reload/register allocation question and possible patch. While
>> working on the Aarch64 SIMD ABI[1] I ran into a problem where GCC was
>> saving and restoring registers that it did not need to. I tracked it
>> down to lra
69 matches
Mail list logo
