power10: Add tests for PCREL_OPT.
This patch add the PCREL_OPT tests for the previous two patches.
I have built compilers with and without these set of 3 patches doing a
bootstrap build and make check. There were no regressions, and the new tests
passed. Can I check these patches into the
power10: Add PCREL_OPT store support.
This patch adds support for optimizing power10 stores to an external variable to
eliminate loading the address of the variable, and then doing a subsequent load
using that address.
The previous patch added the support for optimizing power10 loads from an
power10: Add PCREL_OPT load support.
This patch adds support for optimizing power10 loads of an external variable to
eliminate loading the address of the variable, and then doing a subsequent load
using that address.
The next patch will add the support for optimizing power10 stores to an
The ELF-v2 ISA 3.1 support for Power10 has relocations to optimize cases where
the code is references an external variable in only one location. This patch
is similar to the optimizations that the linker already does to optimize TOC
accesses.
This patch is a revision of the patches last
This patch fixes a long-standing bug in reshape_init_r. Since r209314
we implement DR 1467 which handles list-initialization with a single
initializer of the same type as the target. In this test this causes
a crash in reshape_init_r when we're processing a constructor that has
undergone the DR
From: Sergei Trofimovich
gcc/ChangeLog:
* gcc/profile.c (sort_hist_values): Clarify hist format:
start with a value, not counter.
---
gcc/profile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/profile.c b/gcc/profile.c
index f5c206813c7..fe8963cc9e9
Hi,
Array concatenate expressions were creating more SAVE_EXPRs than what
was necessary. The internal error itself was the result of a forced
temporary being made on a TREE_ADDRESSABLE type.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32.
Committed to mainline and backported
Richard, thank you for working on this issue and for as usually detailed
explanation of the problem.
On 2020-08-28 9:52 a.m., Richard Sandiford wrote:
...
The patch is quite aggressive in that it does this for all reload
pseudos in all reload instructions. I wondered about reusing the
On Sat, 29 Aug 2020, Hu Jiangping wrote:
> This patch add 'cd' command before 'make check-gcc' command
> when run the testsuite on selected tests.
No, don't do that; those targets work fine from the toplevel
too, and then include the language libs.
> Richard and I agree it would be good for
> On Sep 4, 2020, at 1:04 PM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 04, 2020 at 12:18:12PM -0500, Qing Zhao wrote:
>>> I call this very expensive, already,
>>
>> Yes, I think that 17.56% on average is quite expensive. That’s the data for
>> -fzero-call-used-regs=all, the worst case
On Fri, Sep 4, 2020 at 11:09 AM Segher Boessenkool
wrote:
>
> On Fri, Sep 04, 2020 at 10:34:23AM -0700, H.J. Lu wrote:
> > > You probably have to do this for every target separately? But it is not
> > > enough to handle it in the epilogue, you also need to make sure it is
> > > done on every
On Fri, Sep 04, 2020 at 10:34:23AM -0700, H.J. Lu wrote:
> > You probably have to do this for every target separately? But it is not
> > enough to handle it in the epilogue, you also need to make sure it is
> > done on every path that returns *without* epilogue.
>
> This feature is designed for
On Fri, Sep 04, 2020 at 12:18:12PM -0500, Qing Zhao wrote:
> > I call this very expensive, already,
>
> Yes, I think that 17.56% on average is quite expensive. That’s the data for
> -fzero-call-used-regs=all, the worst case i.e, clearing all the call-used
> registers at the return.
>
>
On Fri, Sep 4, 2020 at 8:18 AM Segher Boessenkool
wrote:
>
> Hi!
>
> On Mon, Aug 24, 2020 at 03:49:50PM -0500, Qing Zhao wrote:
> > > Do you want to do this before or after the epilogue code is generated?
> >
> > static rtx_insn *
> > make_epilogue_seq (void)
> > {
> > if
> On Sep 4, 2020, at 10:43 AM, Segher Boessenkool
> wrote:
>
> On Thu, Sep 03, 2020 at 10:13:35AM -0700, Kees Cook wrote:
>> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote:
>>> On average, all the options starting with “used_…” (i.e, only the
>>> registers that are used in the
On 9/3/20 2:44 PM, Martin Sebor wrote:
On 9/1/20 1:22 PM, Jason Merrill wrote:
On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote:
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element. That's correct for
the latter but wrong for
Hi!
On Fri, Sep 04, 2020 at 12:44:17PM -0300, Raoni Fassina Firmino wrote:
> > > + switch (INTVAL (operands[1]))
> > > +{
> > > +case (1 << (31 - 6)): /* FE_INEXACT */
> >
> > I would just write it as 0x02000 etc.? much clearer, and you have
> > the comment demagicificating it
Excerpts from Alan Modra's message of September 4, 2020 3:34 pm:
> So this one is on top of the previously posted patch.
>
> * d-demangle.c (string_need): Take a size_t n arg, and use size_t tem.
> (string_append): Use size_t n.
> (string_appendn, string_prependn): Take a size_t
Changes since v1[1]:
- Fixed english spelling;
- Fixed code-style;
- Changed match operand predicate in feclearexcept and feraiseexcept;
- Changed testcase options;
- Minor changes in test code to be C90 compatible;
- Other minor changes sugested by Segher;
- Changed subject line tag
Hi Segher,
on 2020/9/4 下午10:16, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 04, 2020 at 04:47:37PM +0800, Kewen.Lin wrote:
Apart from that, one P9 specific point is that the update form load isn't
preferred, the reason is that the instruction can not retire until both
parts
Hi,
I am about to sent a v2, but thought to reply here as well.
On Tue, Aug 18, 2020 at 07:09:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Aug 14, 2020 at 07:54:23PM -0300, Raoni Fassina Firmino via
> Gcc-patches wrote:
> > So, this patch adds new rs6000 expand optimizations for
On Thu, Sep 03, 2020 at 10:13:35AM -0700, Kees Cook wrote:
> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote:
> > On average, all the options starting with “used_…” (i.e, only the
> > registers that are used in the routine will be zeroed) have very low
> > runtime overheads, at most
Hi Andrea,
on 2020/9/4 下午8:11, Andrea Corallo wrote:
> Hi all,
>
> just a small patch removing a piece of unreachable code in
> 'vect_estimate_min_profitable_iters' given the condition
> (LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
> checked just above.
>
FWIW, I had
On Mon, Aug 24, 2020 at 03:43:11PM -0500, Qing Zhao wrote:
> > On Aug 24, 2020, at 3:20 PM, Segher Boessenkool
> > wrote:
> >> For this testing? (Is CPU2017 good enough)?
> >
> > I would use something more real-life, not 12 small pieces of code.
>
> Then, what kind of real-life benchmark you
Hi!
On Mon, Aug 24, 2020 at 03:49:50PM -0500, Qing Zhao wrote:
> > Do you want to do this before or after the epilogue code is generated?
>
> static rtx_insn *
> make_epilogue_seq (void)
> {
> if (!targetm.have_epilogue ())
> return NULL;
>
> start_sequence ();
> emit_note
On Thu, Sep 03, 2020 at 04:46:43PM -0300, Alexandre Oliva wrote:
> On Sep 3, 2020, Segher Boessenkool wrote:
> > The idea is that none of them will need adjustment. This hook runs
> > before the "none" code will run, and it can just clear all clobbers
> > then.
>
> Uhh... That's not how asm
Hi!
On Thu, Sep 03, 2020 at 04:31:35PM -0300, Alexandre Oliva wrote:
> Except when it doesn't ;-)
Heh. PRs welcome :-)
> Under:
>
> /* If the actions of the earlier insns must be kept
> in addition to substituting them into the latest one,
> we must make a new PARALLEL for the
On Fri, 2020-09-04 at 03:47 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 04, 2020 at 08:55:43AM +0200, Richard Biener wrote:
> > On Thu, Sep 3, 2020 at 8:10 PM Segher Boessenkool
> > wrote:
> > > On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> > > > On Wed, 2020-09-02
> On Sep 3, 2020, at 8:23 PM, Rodriguez Bahena, Victor
> wrote:
>
>
>
> -Original Message-
> From: Qing Zhao mailto:qing.z...@oracle.com>>
> Date: Thursday, September 3, 2020 at 12:55 PM
> To: Kees Cook mailto:keesc...@chromium.org>>
> Cc: Segher Boessenkool
Hi!
On Fri, Sep 04, 2020 at 04:47:37PM +0800, Kewen.Lin wrote:
> >> Apart from that, one P9 specific point is that the update form load isn't
> >> preferred, the reason is that the instruction can not retire until both
> >> parts complete, it can hold up subsequent instructions from retiring.
>
Hello,
On 03 сен 08:17, H.J. Lu wrote:
> On Thu, Sep 3, 2020 at 8:08 AM Kirill Yukhin via Gcc-patches
> wrote:
> >
> > Hello,
> >
> > On 06 июл 09:58, Hongyu Wang via Gcc-patches wrote:
> > > Hi:
> > >
> > > This patch is about to support Intel Advanced Matrix Extensions (AMX)
> > > which will
Hi Bin,
On Fri, Sep 04, 2020 at 04:27:32PM +0800, Bin.Cheng wrote:
> On Fri, Sep 4, 2020 at 6:37 AM Segher Boessenkool
> wrote:
> > It should have cost, certainly, but not address_cost I think. The total
> > cost of an ldu should be a tiny bit less than that of ld + that of addi;
> > the
The following adds the capability to code-generate live lanes in
basic-block vectorization using lane extracts from vector stmts
rather than keeping the original scalar code around for those.
This eventually makes previously not profitable vectorizations
profitable (the live scalar code was
So this one is on top of the previously posted patch.
* d-demangle.c (string_need): Take a size_t n arg, and use size_t tem.
(string_append): Use size_t n.
(string_appendn, string_prependn): Take a size_t n arg.
(TEMPLATE_LENGTH_UNKNOWN): Define as -1UL.
*
On Fri, Sep 4, 2020 at 11:32 AM Hu, Jiangping
wrote:
>
> > I think the pages under gcc.gnu.org/projects/ are all hopelessly
> > out-of-date and more recent (but still usually out-of-date) info
> > is found on the wiki.
> >
> > So I'm not sure these kind of changes make sense.
> >
> > Eventually
On Tue, 1 Sep 2020, Martin Storsjö wrote:
Previously, the SEH version of _Unwind_Backtrace did unwind
the stack and call the provided callback function as intended,
but there was little the caller could do within the callback to
actually get any info about that particular level in the unwind.
Hi,
On Fri, 4 Sep 2020, Jakub Jelinek wrote:
On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote:
This fixes compilation of codepaths for dos-like filesystems
with Clang. When built with clang, it treats C input files as C++
when the compiler driver is invoked in C++ mode,
This refines the previous fix for PR96698 by re-doing how and where
we arrange for setting vectorized cycle PHI backedge values.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-09-04 Richard Biener
PR tree-optimization/96698
PR
Richard Biener writes:
> On Fri, 4 Sep 2020, Andrea Corallo wrote:
>
>> Hi all,
>>
>> just a small patch removing a piece of unreachable code in
>> 'vect_estimate_min_profitable_iters' given the condition
>> (LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
>> checked just
On Fri, 4 Sep 2020, Andrea Corallo wrote:
> Hi all,
>
> just a small patch removing a piece of unreachable code in
> 'vect_estimate_min_profitable_iters' given the condition
> (LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
> checked just above.
>
> Bootstrapped on
Hi all,
just a small patch removing a piece of unreachable code in
'vect_estimate_min_profitable_iters' given the condition
(LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)) is always true as
checked just above.
Bootstrapped on aarch64-unknown-linux-gnu.
Okay for trunk?
Andrea
>From
Excerpts from Alan Modra's message of September 4, 2020 2:59 am:
> On Thu, Sep 03, 2020 at 11:02:50PM +0200, Iain Buclaw wrote:
>> Excerpts from Alan Modra's message of September 3, 2020 3:01 pm:
>> > Running the libiberty testsuite
>> > ./test-demangle < libiberty/testsuite/d-demangle-expected
>>
On 03/09/2020 09:24, Christophe Lyon via Gcc-patches wrote:
> This patch moves the move-immediate splitter after the regular ones so
> that it has lower precedence, and updates its constraints.
>
> For
> int f3 (void) { return 0x1100; }
> int f3_2 (void) { return 0x12345678; }
>
> we now
template
class GTY((user)) int_range : public irange
{
so people can use
int_range x;
and get the max range by default?
Indeed, I had forgotten about default template arguments, the only
problem is
int_range x;
is valid in c++17, but previous to that we have to do
int_range<> x;
Its a
Hi!
On Fri, Sep 04, 2020 at 05:18:49PM +0800, luoxhu wrote:
> On 2020/9/4 15:23, Richard Biener wrote:
> > On Fri, Sep 4, 2020 at 9:19 AM Richard Biener
> > wrote:
> >> On Fri, Sep 4, 2020 at 8:38 AM luoxhu wrote:
> >>> On 2020/9/4 14:16, luoxhu via Gcc-patches wrote:
> Another problem is
The testcase shows that we fail to clear gimple_call_ctrl_altering_p
when the last abnormal edge goes away, causing an edge insert to
a loop header edge when we have preheaders to split the edge
unnecessarily.
The following addresses this by more aggressively clearing the
flag in
On Fri, 4 Sep 2020, Jakub Jelinek wrote:
> Hi!
>
> As discussed yesterday, stream_input_location_now has been used in 3
> remaining places. For ERT_MUST_NOT_THROW, I believe the failure_loc
> location is stable at least until the apply_cache after the bbs are all
> read, and the locations do
On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote:
> This fixes compilation of codepaths for dos-like filesystems
> with Clang. When built with clang, it treats C input files as C++
> when the compiler driver is invoked in C++ mode, triggering errors
> when the return value of
On Fri, 4 Sep 2020, Jakub Jelinek wrote:
> Hi!
>
> As discussed yesterday:
> On the streamer out side, we call clear_line_info
> in multiple spots which resets the current_* values to something, but on the
> reader side, we don't have corresponding resets in the same location, just
> have
> the
> I think the pages under gcc.gnu.org/projects/ are all hopelessly
> out-of-date and more recent (but still usually out-of-date) info
> is found on the wiki.
>
> So I'm not sure these kind of changes make sense.
>
> Eventually we should remove those pages? Or do we want
> to keep them for
On 9/1/20 1:01 PM, Martin Storsjö wrote:
> This fixes compilation of codepaths for dos-like filesystems
> with Clang. When built with clang, it treats C input files as C++
> when the compiler driver is invoked in C++ mode, triggering errors
> when the return value of strchr() on a pointer to const
On 2020/9/4 15:23, Richard Biener wrote:
> On Fri, Sep 4, 2020 at 9:19 AM Richard Biener
> wrote:
>>
>> On Fri, Sep 4, 2020 at 8:38 AM luoxhu wrote:
>>>
>>>
>>>
>>> On 2020/9/4 14:16, luoxhu via Gcc-patches wrote:
Hi,
Yes, I checked and found that both vec_set and
Hi!
As discussed yesterday, stream_input_location_now has been used in 3
remaining places. For ERT_MUST_NOT_THROW, I believe the failure_loc
location is stable at least until the apply_cache after the bbs are all
read, and the locations do not include BLOCK, so we can use normal
Hi!
On Fri, Sep 04, 2020 at 08:55:43AM +0200, Richard Biener wrote:
> On Thu, Sep 3, 2020 at 8:10 PM Segher Boessenkool
> wrote:
> > On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> > > On Wed, 2020-09-02 at 05:13 -0500, Segher Boessenkool wrote:
> > > > On Tue, Sep 01, 2020 at
Hi Segher,
>> Good question! I agree that they can execute in parallel, but it depends
>> on how we interprete the addressing cost, if it's for required execution
>> resource, I think it's off, since comparing with ld, the ldu has two iops
>> and extra ALU requirement.
>
> OTOH, if you do not
Hi!
As discussed yesterday:
On the streamer out side, we call clear_line_info
in multiple spots which resets the current_* values to something, but on the
reader side, we don't have corresponding resets in the same location, just have
the stream_* static variables that keep the current values
Hi!
CCing build maintainers now.
On Thu, Sep 03, 2020 at 04:49:09PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Sep 03, 2020 at 03:53:35PM +0200, Richard Biener wrote:
> > No review on the actual patch - it looks like what I'd have tried
> > but I'm no make expert ;)
Successfully
On Fri, Sep 4, 2020 at 6:37 AM Segher Boessenkool
wrote:
>
> On Thu, Sep 03, 2020 at 10:24:21AM +0800, Kewen.Lin wrote:
> > on 2020/9/2 下午6:25, Segher Boessenkool wrote:
> > > On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote:
> > >> on 2020/9/1 上午3:41, Segher Boessenkool wrote:
> > >>>
Hi David.
> This patch updates the BPF back end to generate indirect calls via
> the 'call %reg' instruction when targetting xBPF.
>
> Additionally, the BPF ASM_SPEC is updated to pass along -mxbpf to
> gas, where it is now supported.
Thanks for the patch.
I just installed it on your behalf.
Please find attached a fix for PR95614. The original patch was by Steve
Kargl.
The original patch resulted in name clashes between global identifiers
naming common blocks and local identifiers. According to the 2018
standard 19.3.1 Classes of local identifiers, item 2, a local identifier
On Fri, Sep 4, 2020 at 9:19 AM Richard Biener
wrote:
>
> On Fri, Sep 4, 2020 at 8:38 AM luoxhu wrote:
> >
> >
> >
> > On 2020/9/4 14:16, luoxhu via Gcc-patches wrote:
> > > Hi,
> > >
> > >
> > > Yes, I checked and found that both vec_set and vec_extract doesn't support
> > > variable index for
On Fri, Sep 4, 2020 at 8:38 AM luoxhu wrote:
>
>
>
> On 2020/9/4 14:16, luoxhu via Gcc-patches wrote:
> > Hi,
> >
> >
> > Yes, I checked and found that both vec_set and vec_extract doesn't support
> > variable index for most targets, store_bit_field_1 and extract_bit_field_1
> > would only
On Fri, Sep 4, 2020 at 8:33 AM Hu Jiangping wrote:
>
> Although vectorization.html is not up-to-date, it is still
> easy to be searched, and the deprecated flag in it may
> confuse users. This patch simply adds a note to the head
> of the page, hoping to help users who read it.
>
> OK for
On Thu, Sep 3, 2020 at 8:10 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> > On Wed, 2020-09-02 at 05:13 -0500, Segher Boessenkool wrote:
> > > On Tue, Sep 01, 2020 at 09:00:20PM -0500, will schmidt wrote:
> > > > This corrects an issue
On 2020/9/4 14:16, luoxhu via Gcc-patches wrote:
Hi,
Yes, I checked and found that both vec_set and vec_extract doesn't support
variable index for most targets, store_bit_field_1 and extract_bit_field_1
would only consider use optabs when index is integer value. Anyway, it
shouldn't be
Although vectorization.html is not up-to-date, it is still
easy to be searched, and the deprecated flag in it may
confuse users. This patch simply adds a note to the head
of the page, hoping to help users who read it.
OK for master?
Regards!
Hujp
---
Hi,
On 2020/9/3 18:29, Richard Biener wrote:
> On Thu, Sep 3, 2020 at 11:20 AM luoxhu wrote:
>>
>>
>>
>> On 2020/9/2 17:30, Richard Biener wrote:
so maybe bypass convert_vector_to_array_for_subscript for special
circumstance
like "i = v[n%4]" or "v[n&3]=i" to generate vec_extract
>> Hi,
>>
>> On Mon, Aug 31 2020, Feng Xue OS wrote:
>> > This patch is to fix a bug that cost that is used to evaluate clone
>> > candidate
>> > becomes negative due to integer overflow.
>> >
>> > Feng
>> > ---
>> > 2020-08-31 Feng Xue
>> >
>> > gcc/
>> > PR tree-optimization/96806
>>
68 matches
Mail list logo
