I reconsider the issue and update patch attached.
Yes, If the kernel loop bb's information doesn't use in regrename, it also need
not be collected to save compile time.
> -Original Message-
> From: Zhongyunde
> Sent: Sunday, July 26, 2020 3:29 PM
> To: 'Richard Sandiford'
> Cc:
Hi Richard,
Thanks for the review again!
on 2020/7/25 上午12:21, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>
> Thanks, the rearrangement of the existing code looks good. Could you
> split that and the new LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo) stuff
> out into separate patches?
>
Hi Segher,
Thanks for the comments!
on 2020/7/23 上午1:49, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 22, 2020 at 09:26:39AM +0800, Kewen.Lin wrote:
>> +/* For some target specific vectorization cost which can't be handled per
>> stmt,
>> + we check the requisite conditions and adjust the
Hi,
As Richard S. suggested in the thread:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html
this patch is separated from the one of that thread, mainly to refactor the
existing peel_iters_{pro,epi}logue cost model handlings.
I've addressed Richard S.'s review comments there,
Again, the variables are "privatized" using ASM_PN_FORMAT for MMIX (but
apparently not for other targets) and the line to match looks like:
D.1427 = VEC_PERM_EXPR ;
gcc/testsuite:
* gcc.dg/tree-ssa/vector-4.c: Adjust for mmix.
--- gcc/gcc/testsuite/gcc.dg/tree-ssa/vector-4.c.orig Mon
The variables are "localized" using ASM_PN_FORMAT for MMIX and the
lines to match look like:
Deleted dead store: y::4 = y;
Deleted dead store: x::3 = x;
gcc/testsuite:
* gcc.dg/tree-ssa/ssa-dse-26.c: Adjust for mmix.
--- gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c.orig Wed Feb 12
Looking at the dump and the test, I guess all "64-bit targets" fail
the test for the reasons seen in the comment just above the dg-final,
whose last two lines make it to the patch context. Maybe the xfail
target list can be shortened by removing most targets and use just
"lp64". That doesn't
The expression of interest looks like "e_5 = a::0_1 + b::1_2;" for
mmix-knuth-mmixware, while other targets have a "." instead of the
"::". ISTM the most useful change here is not to disable the test,
but to add an optional character in the matched expression to match
the "extra" ":". Also
In 2012 e2769e908a915ebbc/r192344, I added the following lines, that I
now delete. I've changed my mind: ELF-related targets based on gas,
that support only static linking, have .hidden "for free", regardless
of the visibility of the hidden object in the linked executable. No
regressions for
Hello!
> Tag the floating-point calling convention used on m68k-elf (either hard-float
> or soft-float) through the GNU assembler attribute. The use of the tag enables
> the linker to ensure linked objects use a consistent floating-point ABI and
> allows tools like GDB to infer the ABI used from
Hello!
> Tag the floating-point calling convention used on m68k-elf (either hard-float
> or soft-float) through the GNU assembler attribute. The use of the tag enables
> the linker to ensure linked objects use a consistent floating-point ABI and
> allows tools like GDB to infer the ABI used from
> As you see, I really do not like to have another RTX class, without very
> well defined semantics even. Not without first being shown no
> alternatives are acceptable, anyway :-)
Seconded.
--
Eric Botcazou
We successfully compile this testcase ever since r8-5270.
gcc/testsuite/ChangeLog:
PR c++/79504
* g++.dg/cpp0x/decltype79.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/decltype79.C | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/13/20 6:05 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/7/20 12:56 PM, Martin Sebor wrote:
Ping. Despite its size, there isn't much new in the patch, it
pretty
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
On 7/16/20 4:53 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
(Jeff, I forgot to mention this patch when we spoke earlier today.)
On 7/8/20 6:01 PM, Martin Sebor wrote:
GCC
On Sun, Jul 26, 2020 at 4:02 AM Andreas Schwab wrote:
>
> On Jul 25 2020, Fāng-ruì Sòng wrote:
>
> > On Sat, Jul 25, 2020 at 12:09 AM Andreas Schwab
> > wrote:
> >>
> >> On Jul 24 2020, Fangrui Song via Gcc-patches wrote:
> >>
> >> > This is to mimick nearly lines. collect2 should filter out
On 24/07/2020 8:27 am, Thomas Schwinge wrote:
That however completely defeats what we're intending to test here, which
is to "Test invalid intra-routine parallelism". The same problem has
been introduced in og10 commit 6a0b5806b24bfdefe0b0f3ccbcc51299e5195dca
"Various OpenACC reduction
On Jul 25 2020, Fāng-ruì Sòng wrote:
> On Sat, Jul 25, 2020 at 12:09 AM Andreas Schwab wrote:
>>
>> On Jul 24 2020, Fangrui Song via Gcc-patches wrote:
>>
>> > This is to mimick nearly lines. collect2 should filter out options like
>> > -fno-lto, -flto, -fuse-ld= before passing to ld. -f* are
> >> It's interesting that this is for a testcase using SMS. One of the
> >> traditional problems with the GCC implementation of SMS has been
> >> ensuring that later passes don't mess up the scheduled loop. So in
> >> your testcase, does register allocation succeed for the SMS loop
> >>
On Sat, Jul 25, 2020 at 12:09 AM Andreas Schwab wrote:
>
> On Jul 24 2020, Fangrui Song via Gcc-patches wrote:
>
> > This is to mimick nearly lines. collect2 should filter out options like
> > -fno-lto, -flto, -fuse-ld= before passing to ld. -f* are handled by case
> > 'f'. --ld-path needs its
20 matches
Mail list logo
