On 2023-08-03 21:18, Andrew MacLeod wrote:
This is OK.
Thanks a lot! Committed via r14-3582.
BR,
Jeff (Jiufu Guo)
On 8/2/23 22:18, Jiufu Guo wrote:
Hi,
I would like to have a ping on this patch.
BR,
Jeff (Jiufu Guo)
Jiufu Guo writes:
Hi,
As discussed in previous reviews, adding
Hi,
I would like to have a gentle ping...
BR,
Jeff (Jiufu Guo)
On 2023-08-07 10:45, guojiufu via Gcc-patches wrote:
Hi,
Gentle ping...
On 2023-07-18 22:05, Jiufu Guo wrote:
Hi,
Integer expression "(X - N * M) / N" can be optimized to "X / N - M"
if there is no wra
Hi Segher,
As discussed on "~" vs. "-", "~" is correct for this patch.
I updated the patch according to Kewen's comments.
If ok, I would commit to trunk.
BR,
Jeff (Jiufu Guo)
On 2023-07-04 11:28, Kewen.Lin wrote:
Hi Jeff,
on 2023/7/4 10:18, Jiufu Guo via Gcc-patches wrote:
Hi,
If a
Hi,
Gentle ping...
On 2023-07-18 22:05, Jiufu Guo wrote:
Hi,
Integer expression "(X - N * M) / N" can be optimized to "X / N - M"
if there is no wrap/overflow/underflow and "X - N * M" has the same
sign with "X".
Compare the previous version:
On 2023-08-02 20:41, Richard Biener wrote:
On Tue, 1 Aug 2023, Jiufu Guo wrote:
Hi,
Richard Biener writes:
> On Mon, 24 Jul 2023, Jiufu Guo wrote:
>
>>
>> Hi Martin,
>>
>> Not sure about your current option about re-using the ipa-sra code
>> in the light-expander-sra. And if anything I
On 2023-06-13 17:18, Jiufu Guo via Gcc-patches wrote:
Hi David,
Thanks for your valuable comments!
David Edelsohn writes:
...
Do you have any measurement of how expensive it is to test all of
these additional methods to generate a constant? How much does this
affect the
compile time?
Hi,
On 2023-06-09 16:00, Richard Biener wrote:
On Fri, 9 Jun 2023, Jiufu Guo wrote:
Hi,
As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P
(mode))"
in "try_const_anchors".
This assert seems correct because the function try_const_anchors cares
about integer values currently,
Hi,
On 2023-06-05 00:59, Jeff Law wrote:
On 5/9/23 07:43, Jiufu Guo wrote:
Thanks for point out this! Yes, BLKmode rtx may not always be a MEM.
MEM_SIZE is only ok for MEM after the it's known size is computed.
Here MEM_SIZE is fine just because it is an stack rtx corresponding
to the type
Hi,
On 2023-05-15 14:53, Kewen.Lin wrote:
Hi Jeff,
on 2022/12/12 09:38, Jiufu Guo wrote:
Hi,
For constant C:
If '(c & 0xULL) == 0x' or say:
32(1) || 1(0) || 15(x) || 16(0), we could use "lis; xoris" to build.
Here N(M) means N continuous bit M, x for M means
Hi,
On 2023-04-26 17:35, Kewen.Lin wrote:
Hi Jeff,
on 2023/1/4 14:51, Jiufu Guo wrote:
Hi,
Compare with previous version, this patch updates the comments only.
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608293.html
For a complicate 64bit constant, below is one
Hi,
On 2023-05-01 23:52, Segher Boessenkool wrote:
Hi!
On Fri, Mar 17, 2023 at 11:39:52AM +0800, Jiufu Guo wrote:
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr65421-1.c: New test.
* gcc.target/powerpc/pr65421.c: New test.
Please name the tests something else? -1.c and
Hi,
On 2023-05-01 03:00, Jeff Law wrote:
On 3/16/23 21:39, Jiufu Guo wrote:
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, and the parameter/return is passed
through registers.
For this kind of case, it would be better to use the nature
Hi Kewen,
On 2023-04-19 10:53, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/19 10:03, Jiufu Guo wrote:
Hi,
On P7, option -mno-allow-movmisalign is added during testing, which
prevents slp happen on the case.
Like Like PR65484 and PR87306, this patch use vect_hw_misalig to guard
Dup like...
On 2023-04-14 17:09, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/14 16:01, guojiufu wrote:
On 2023-04-14 15:30, Jiufu Guo wrote:
Hi,
As PR108809 mentioned, vec_xl_len_r and vec_xst_len_r are tested
in gcc.target/powerpc/builtins-5-p9-runnable.c.
The vector operand of these two bifs are different
On 2023-04-14 15:30, Jiufu Guo wrote:
Hi,
As PR108809 mentioned, vec_xl_len_r and vec_xst_len_r are tested
in gcc.target/powerpc/builtins-5-p9-runnable.c.
The vector operand of these two bifs are different from the view
of v16_int8 between BE and LE, even it is same from the view of
Hi,
On 2023-04-13 20:08, Segher Boessenkool wrote:
On Thu, Apr 13, 2023 at 07:39:01AM +, Richard Biener wrote:
On Thu, 13 Apr 2023, Jiufu Guo wrote:
I think this should be fixed in the analyzer, "stripping" malloc
tracking from fopen/fclose since it does this manually. I've adjusted
the
Hi,
On 2023-04-12 20:47, Kewen.Lin wrote:
Hi Segher & Jeff,
on 2023/4/11 23:13, Segher Boessenkool wrote:
On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
on 2023/4/11 17:14, guojiufu wrote:
Thanks for raising this concern.
The behavior to check about bif on FLOAT128_HW and emit
Hi Mike,
On 2023-04-12 22:46, Michael Meissner wrote:
On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote:
I understand that QP insns (e.g. xscmpexpqp) is valid if the system
meets ISA3.0, no matter BE/LE, 32-bit/64-bit.
I think option -mfloat128-hardware is designed for QP insns.
While
Hi Kewen,
Thanks a lot for your very helpful comments!
On 2023-04-10 17:26, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
Hi,
In this test case (float128-cmp2-runnable.c), the instruction
xscmpexpqp is used to support a few builtins e.g.
Hi,
On 2022-12-21 15:30, Richard Biener wrote:
On Wed, 21 Dec 2022, Jiufu Guo wrote:
Hi,
This patch is fixing an issue about parameter accessing if the
parameter is struct type and passed through integer registers, and
there is floating member is accessed. Like below code:
typedef struct DF
On 2022-12-01 15:10, Jiufu Guo via Gcc-patches wrote:
Hi Kewen,
在 12/1/22 2:11 PM, Kewen.Lin 写道:
on 2022/12/1 13:35, Jiufu Guo wrote:
Hi Kewen,
Thanks for your quick and insight review!
在 12/1/22 1:17 PM, Kewen.Lin 写道:
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
Hi,
This patch just
On 2/22/22 PM3:26, Richard Biener wrote:
On Tue, 22 Feb 2022, Jiufu Guo wrote:
Hi,
For constants, there are some codes to check: if it is able to put
to instruction as an immediate operand or it is profitable to load from
mem. There are still some places that could be improved for
On 2022-02-23 01:30, Segher Boessenkool wrote:
Hi Jiu Fu,
On Tue, Feb 22, 2022 at 02:53:13PM +0800, Jiufu Guo wrote:
static bool
rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED,
rtx x)
{
- if (GET_CODE (x) == HIGH
- && GET_CODE (XEXP (x, 0)) == UNSPEC)
+ if
On 2022-01-03 22:30, Richard Biener wrote:
On Wed, 22 Dec 2021, Jiufu Guo wrote:
Hi,
Normaly, estimate_numbers_of_iterations get/caculate niter first,
and then invokes infer_loop_bounds_from_undefined. While in some case,
after a few call stacks, estimate_numbers_of_iterations is invoked
I just had a test on ppc64le, this patch pass bootstrap and regtest.
Is this patch OK for trunk?
Thanks for any comments.
BR,
Jiufu
On 2021-10-18 21:37, Jiufu Guo wrote:
With reference the discussions in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
On 2021-10-20 10:44, Andrew Pinski wrote:
On Tue, Oct 19, 2021 at 7:30 PM Jiufu Guo via Gcc-patches
wrote:
In tree_simplify_using_condition_1, there is code which should be
logic:
"op0 || op1"/"op0 && op1". When creating expression for TRUTH_OR_EXPR
and TRUTH_AND_EXPR, fold_build2 would be
On 2021-08-31 20:12, Jakub Jelinek wrote:
Hi!
I'm getting:
FAIL: gcc.dg/vect/pr101145.c scan-tree-dump-times vect "vectorized 1
loops" 7
FAIL: gcc.dg/vect/pr101145_1.c scan-tree-dump-times vect "vectorized 1
loops" 2
FAIL: gcc.dg/vect/pr101145_2.c scan-tree-dump-times vect "vectorized 1
On 2021-08-30 20:02, Richard Biener wrote:
On Mon, 30 Aug 2021, guojiufu wrote:
On 2021-08-30 14:15, Jiufu Guo wrote:
> Hi,
>
> In patch r12-3136, niter->control, niter->bound and niter->cmp are
> derived from number_of_iterations_lt. While for 'until wrap condition',
> the calculation in
On 2021-08-30 14:15, Jiufu Guo wrote:
Hi,
In patch r12-3136, niter->control, niter->bound and niter->cmp are
derived from number_of_iterations_lt. While for 'until wrap
condition',
the calculation in number_of_iterations_lt is not align the
requirements
on the define of them and
On 2021-08-16 09:33, Bin.Cheng wrote:
On Wed, Aug 4, 2021 at 10:42 AM guojiufu
wrote:
...
>> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145.inc
>> b/gcc/testsuite/gcc.dg/vect/pr101145.inc
>> new file mode 100644
>> index 000..6eed3fa8aca
>> --- /dev/null
>> +++
Hi,
I would like to have a ping on this.
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574596.html
BR,
Jiufu
On 2021-07-15 08:17, guojiufu via Gcc-patches wrote:
Hi,
I would like to have an early ping on this with more mail addresses.
BR,
Jiufu.
On 2021-07-07 20:47, Jiufu Guo wrote
On 2021-07-27 23:40, Jeff Law wrote:
On 7/27/2021 12:27 AM, Richard Biener wrote:
On Fri, 23 Jul 2021, Jeff Law wrote:
On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote:
Refine code for V2 according to review comments:
* Use if check instead assert, and refine assert
* Use better RE
On 2021-06-21 20:36, Richard Biener wrote:
On Mon, 21 Jun 2021, guojiufu wrote:
On 2021-06-21 14:19, guojiufu via Gcc-patches wrote:
> On 2021-06-09 19:18, guojiufu wrote:
>> On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
>>> On 2021-06-08 18:13, Richard Biener wrote:
On 2021-07-15 14:06, Richard Biener wrote:
On Tue, 13 Jul 2021, Jiufu Guo wrote:
Major changes from v1:
* Add target hook to query preferred doloop mode.
* Recompute doloop iv base from niter under preferred mode.
Currently, doloop.xx variable is using the type as niter which may
shorter
On 2021-07-15 02:04, Segher Boessenkool wrote:
Hi!
On Wed, Jul 14, 2021 at 06:26:28PM +0800, guojiufu wrote:
PR target/61837
Wrong PR number?
There is a patch optimize "add -1; zero_ext; add +1" to "zero_ext"
already.
Having this patch would help to avoid the left 'zero_ext', so,
Hi,
I would like to have an early ping on this with more mail addresses.
BR,
Jiufu.
On 2021-07-07 20:47, Jiufu Guo wrote:
Changes since v1:
* Update assumptions for niter, add more test cases check
* Use widest_int/wide_int instead mpz to do +-/
* Move some early check for quick return
For
On 2021-07-14 12:40, guojiufu via Gcc-patches wrote:
Updated the patch as below:
Thanks for comments.
gcc/ChangeLog:
2021-07-13 Jiufu Guo
PR target/61837
* config/rs6000/rs6000.c (TARGET_PREFERRED_DOLOOP_MODE): New hook.
(rs6000_preferred_doloop_mode): New hook
On 2021-07-14 04:50, Segher Boessenkool wrote:
Hi!
On Tue, Jul 13, 2021 at 08:50:46PM +0800, Jiufu Guo wrote:
* doc/tm.texi: Regenerated.
Pet peeve: "Regenerate.", no "d".
Ok, yeap. While, 'Regenerate and Regenerated' were used by commits
somewhere :)
+DEFHOOK
On 2021-07-13 23:38, Segher Boessenkool wrote:
On Mon, Jul 12, 2021 at 08:20:14AM +0200, Richard Biener wrote:
On Fri, 9 Jul 2021, Segher Boessenkool wrote:
> Almost all targets just use Pmode, but there is no such guarantee I
> think, and esp. some targets that do not have machine insns for
On 2021-07-13 23:51, Segher Boessenkool wrote:
On Tue, Jul 13, 2021 at 10:09:25AM +0800, guojiufu wrote:
>For loop looks like:
> do ;
> while (n-- > 0); /* while (n-- > low); */
(This whole loop as written will be optimised away, but :-) )
At -O2, the loop is optimized away.
At -O1, the
On 2021-07-13 15:09, Richard Biener wrote:
On Tue, 13 Jul 2021, guojiufu wrote:
On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
> On 2021-07-12 22:46, Richard Biener wrote:
>> On Mon, 12 Jul 2021, guojiufu wrote:
>>
>>> On 2021-07-12 18:02, Richard Biener wrote:
&
On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
On 2021-07-12 22:46, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 18:02, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 16:57, Richard Biener wrote:
>> >
On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
On 2021-07-12 22:46, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 18:02, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 16:57, Richard Biener wrote:
>> >
On 2021-07-12 22:46, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 18:02, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 16:57, Richard Biener wrote:
>> > On Mon, 12 Jul 2021, guojiufu wrote:
>> >
>> >> On 2021-07-12 14:20, Richard
On 2021-07-12 18:02, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 16:57, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 14:20, Richard Biener wrote:
>> > On Fri, 9 Jul 2021, Segher Boessenkool wrote:
>> >
>> >> On Fri, Jul 09, 2021
On 2021-07-12 16:57, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 14:20, Richard Biener wrote:
> On Fri, 9 Jul 2021, Segher Boessenkool wrote:
>
>> On Fri, Jul 09, 2021 at 08:43:59AM +0200, Richard Biener wrote:
>> > I wonder if there's a way to query the target
On 2021-07-12 14:20, Richard Biener wrote:
On Fri, 9 Jul 2021, Segher Boessenkool wrote:
On Fri, Jul 09, 2021 at 08:43:59AM +0200, Richard Biener wrote:
> I wonder if there's a way to query the target what modes the doloop
> pattern can handle (not being too familiar with the doloop code).
"internal loop alignment added" 1
"alignments"} } */
+
--
2.17.1
On 2021-06-18 16:24, guojiufu via Gcc-patches wrote:
On 2021-06-15 12:57, guojiufu via Gcc-patches wrote:
On 2021-06-14 17:16, Jan Hubicka wrote:
On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote:
>
On 2021-07-01 20:35, Richard Biener wrote:
On Thu, 1 Jul 2021, Jiufu Guo wrote:
For code like:
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0;
for (unsigned i = start; i > val; ++i)
cnt++;
return cnt;
}
The number of iterations should be about UINT_MAX - start.
For
On 2021-07-02 08:51, Bin.Cheng wrote:
On Thu, Jul 1, 2021 at 10:15 PM guojiufu via Gcc-patches
wrote:
On 2021-07-01 20:35, Richard Biener wrote:
> On Thu, 1 Jul 2021, Jiufu Guo wrote:
>
>> For code like:
>> unsigned foo(unsigned val, unsigned start)
>>
On 2021-07-01 20:35, Richard Biener wrote:
On Thu, 1 Jul 2021, Jiufu Guo wrote:
For code like:
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0;
for (unsigned i = start; i > val; ++i)
cnt++;
return cnt;
}
The number of iterations should be about UINT_MAX - start.
For
On 2021-07-01 15:22, Bin.Cheng wrote:
On Thu, Jul 1, 2021 at 10:06 AM Jiufu Guo via Gcc-patches
wrote:
For code like:
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0;
for (unsigned i = start; i > val; ++i)
cnt++;
return cnt;
}
The number of iterations should be about
On 2021-06-21 16:51, Richard Biener wrote:
On Wed, 9 Jun 2021, guojiufu wrote:
On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
> On 2021-06-08 18:13, Richard Biener wrote:
>> On Fri, 4 Jun 2021, Jiufu Guo wrote:
>>
> cut...
>>> + gcond *cond = as_a (last)
On 2021-06-21 14:19, guojiufu via Gcc-patches wrote:
On 2021-06-09 19:18, guojiufu wrote:
On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
On 2021-06-08 18:13, Richard Biener wrote:
On Fri, 4 Jun 2021, Jiufu Guo wrote:
cut...
cut...
Besides the method in the previous mails,
I’m
On 2021-06-09 19:18, guojiufu wrote:
On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
On 2021-06-08 18:13, Richard Biener wrote:
On Fri, 4 Jun 2021, Jiufu Guo wrote:
cut...
cut...
Here is the updated patch, thanks for your time!
Updates:
. Enhance code to support negative step
On 2021-06-15 12:57, guojiufu via Gcc-patches wrote:
On 2021-06-14 17:16, Jan Hubicka wrote:
On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote:
> Gentle ping.
>
> Original message:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
I think you need a more agg
On 2021-06-15 12:57, guojiufu via Gcc-patches wrote:
On 2021-06-14 17:16, Jan Hubicka wrote:
On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote:
> Gentle ping.
>
> Original message:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
I think you need a more agg
On 2021-06-14 17:16, Jan Hubicka wrote:
On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote:
> Gentle ping.
>
> Original message:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
I think you need a more aggressive ping :-)
OK for the trunk. Sorry for the lo
On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
On 2021-06-08 18:13, Richard Biener wrote:
On Fri, 4 Jun 2021, Jiufu Guo wrote:
cut...
+ gcond *cond = as_a (last);
+ enum tree_code code = gimple_cond_code (cond);
+ if (!(code == NE_EXPR
+ || (code == EQ_EXPR
On 2021-06-08 18:13, Richard Biener wrote:
On Fri, 4 Jun 2021, Jiufu Guo wrote:
cut...
+ gcond *cond = as_a (last);
+ enum tree_code code = gimple_cond_code (cond);
+ if (!(code == NE_EXPR
+ || (code == EQ_EXPR && (e->flags & EDGE_TRUE_VALUE
The NE_EXPR check
Gentle ping ;)
BR.
Jiufu Guo
On 2021-05-20 15:19, guojiufu via Gcc-patches wrote:
Gentle ping^.
On 2021-05-07 10:36, guojiufu via Gcc-patches wrote:
Gentle ping.
Original message:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
Thanks,
Jiufu Guo.
On 2021-06-01 11:28, guojiufu via Gcc-patches wrote:
On 2021-05-26 17:50, Richard Biener wrote:
On Mon, 17 May 2021, Jiufu Guo wrote:
Or relax all this, of course.
It would easy to handle the above cases: e->src before latch, or simple
header.
To relax this, we may need to p
On 2021-05-26 17:50, Richard Biener wrote:
On Mon, 17 May 2021, Jiufu Guo wrote:
...
while (++k > n)
a[k] = b[k] + 1;
then for the second loop, it could be optimized.
Btw, I think even the first loop should be vectorized. I see we do
not handle it in niter analysis:
Analyzing
On 2021-05-18 14:58, Richard Biener wrote:
On Mon, 17 May 2021, Ian Lance Taylor wrote:
On Mon, May 17, 2021 at 1:17 AM Richard Biener via Gcc-patches
wrote:
>
> On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
> wrote:
> >
> > On 2021-05-14 15:39, guojiufu
Gentle ping^.
On 2021-05-07 10:36, guojiufu via Gcc-patches wrote:
Gentle ping.
Original message:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
Thanks,
Jiufu Guo.
On 2021-05-18 14:58, Richard Biener wrote:
On Mon, 17 May 2021, Ian Lance Taylor wrote:
On Mon, May 17, 2021 at 1:17 AM Richard Biener via Gcc-patches
wrote:
>
> On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
> wrote:
> >
> > On 2021-05-14 15:39, guojiufu
On 2021-05-18 18:32, guojiufu wrote:
On 2021-05-18 17:28, guojiufu via Gcc-patches wrote:
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would
On 2021-05-18 17:28, guojiufu via Gcc-patches wrote:
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would not happen. For example code:
foo (int
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k !=
On 2021-05-17 16:17, Richard Biener wrote:
On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
wrote:
On 2021-05-14 15:39, guojiufu via Gcc-patches wrote:
> On 2021-05-14 15:15, Richard Biener wrote:
>> On May 14, 2021 4:52:56 AM GMT+02:00, Jiufu Guo
>> wrote:
&
I've refined the patch as below.
This patch is checking "unsigned type" adn iv.no_overflow.
While I'm thinking to use "number_of_iterations_exit (loop, e, ,
false, false, NULL)"
and "niter.control.no_overflow" to check overflow/wrap, which maybe
more accurate, but relative "expensive".
On 2021-05-14 15:39, guojiufu via Gcc-patches wrote:
On 2021-05-14 15:15, Richard Biener wrote:
On May 14, 2021 4:52:56 AM GMT+02:00, Jiufu Guo
wrote:
As discussed in the PR, Richard mentioned the method to
figure out which VAR was not set TREE_ADDRESSABLE, and
then cause this failure
On 2021-05-14 15:15, Richard Biener wrote:
On May 14, 2021 4:52:56 AM GMT+02:00, Jiufu Guo
wrote:
As discussed in the PR, Richard mentioned the method to
figure out which VAR was not set TREE_ADDRESSABLE, and
then cause this failure. It is address_expression which
build addr_expr
On 2021-05-06 16:27, Richard Biener wrote:
On Thu, 6 May 2021, guojiufu wrote:
On 2021-05-03 20:18, Richard Biener wrote:
> On Thu, 29 Apr 2021, Jiufu Guo wrote:
>
>> When there is the possibility that overflow may happen on the loop index,
>> a few optimizations would not happen. For example
Gentle ping.
Original message:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
Thanks,
Jiufu Guo.
On 2021-05-03 20:18, Richard Biener wrote:
On Thu, 29 Apr 2021, Jiufu Guo wrote:
When there is the possibility that overflow may happen on the loop
index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k != n)
a[k] = b[k]
On 2021-05-01 05:37, Segher Boessenkool wrote:
Hi!
On Thu, Apr 29, 2021 at 05:50:48PM +0800, Jiufu Guo wrote:
When there is the possibility that overflow may happen on the loop
index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
On 2021-05-01 00:27, Jeff Law wrote:
On 4/29/2021 3:50 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow may happen on the loop
index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k != n)
In PR87473, there are discussions about loop-closed PHIs which
are generated for loop optimization passes. It would be helpful
to clean them up after loop optimization is done, then this may
simplify some jobs of following passes.
This patch introduces a cheaper way to propagate them out in
Hi,
I just had a check on below patch for PR66552.
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540930.html
It seems this patch works fine now. This patch fixes PR66552 which
request to optimizes (x shift (n mod C)) to
(x shift (n bit_and (C - 1))) when C is a constant and power of
When investigating the issue from
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549786.html
I find the BB COUNTs of loop seems are not accurate in some case.
For example:
In below figure:
COUNT:268435456 pre-header
|
|
Hi,
PR68212 mentioned that the COUNT of unrolled loop was not correct, and
comments of this PR also mentioned that loop become 'cold'.
This patch fixes the wrong COUNT/PROB of unrolled loop. And the
patch handles the case where unrolling in unreliable count number can
cause a loop to no longer
Hi,
When investigating the issue from
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549786.html
I find the BB COUNTs of loop seems are not accurate in some case.
For example:
In below figure:
COUNT:268435456 pre-header
|
|
Hi,
When unroll loops, if there are calls inside the loop, those calls
may raise negative impacts for unrolling. This patch adds a param
param_max_unrolled_calls, and checks if the number of calls inside
the loop bigger than this param, loop is prevent from unrolling.
This patch is checking the
Hi,
For very small loops (< 6 insns), it would be fine to unroll 4
times to run fast with less latency and better cache usage. Like
below loops:
while (i) a[--i] = NULL; while (p < e) *d++ = *p++;
With this patch enhances, we could see some performance improvement
for some workloads(e.g.
For very small loops (< 6 insns), it would be fine to unroll 4
times to use cache line better. Like below loops:
`while (i) a[--i] = NULL; while (p < e) *d++ = *p++;`
And for very complex loops which may cause negative impacts:
branch-miss or cache-miss. Like below loop: there are calls,
From: Jiufu Guo
Currently GIMPLE complete unroller(cunroll) is checking
flag_unroll_loops and flag_peel_loops to see if allow size growth.
Beside affects curnoll, flag_unroll_loops also controls RTL unroler.
To have more freedom to control cunroll and RTL unroller, this patch
introduces
From: Jiufu Guo
Previously, flag_unroll_loops was turned on at -O2 implicitly. It
also turned on cunroll with allowance size increasing, and then cunroll
will unroll/peel the loop even the loop is complex like code in PR95018.
With this patch, size growth for cunroll is allowed if
Previously, turning -funroll-loops on at -O2, which also turn on
GIMPLE cunroll fully. While cunroll unrolls some complex loops.
This patch turn on -frtl-unroll-loops at -O2 only, and continue to
use previous tuned rs6000 heurisitics for small loops. While this
patch does not turn on GIMPLE
Currently option -funroll-loops controls both GIMPLE unroler and
RTL unroller. It is not able to control GIMPLE cunroller and
RTL unroller independently. This patch introducing different flags
to control them seperately, and this also provide more freedom to
tune one of them without affecting
Hi,
Previously -fweb was disabled if only unroll small loops. After that
we find there is cases where it could help to rename pseudos and aovid
some anti-dependence which may occur after unroll.
Below is a patch to disable -fweb during loop unrolling.
Bootstrap and regtest pass on powerpc,
91 matches
Mail list logo
