>> If my understanding on this question is correct, IMHO we should try to make
>> IVOPTs conservative than optimistic, since once the predict is wrong from
>> too optimistic decision, the costing on the doloop use is wrong, it's very
>> possible to affect the global optimal set. It looks we don't
Hi,
Gentle ping again. Thanks!
Kewen
on 2019/5/21 上午10:02, Kewen.Lin wrote:
> Hi,
>
> Gentle ping again. Thanks!
>
>
> Kewen
>
> on 2019/5/5 下午2:15, Kewen.Lin wrote:
>> Hi,
>>
>> I'd like to gentle ping for this patch:
>> https://gcc.
Hi,
Many thanks for all comments on previous versions.
Comparing with the previous version, I dropped the checks
on costly niter and invalid stmt scanning. As Richard's
suggestion, keep this as simple as possible, refine it
if finding any cases which matter later.
Bootstrapped and regression t
Hi Segher and Bill,
Thanks a lot for your review comments! I've updated the patch accordingly.
The updated one attached.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 91fafc4e766..6667cd03042 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@
on 2019/6/17 下午4:51, Richard Biener wrote:
> On Mon, 17 Jun 2019, Kewen.Lin wrote:
>
>> Hi Segher and Bill,
>>
>> Thanks a lot for your review comments! I've updated the patch accordingly.
>>
>> The updated one attached.
>
> OK. I suppose all lo
on 2019/6/17 下午8:08, Richard Biener wrote:
> On June 17, 2019 11:59:30 AM GMT+02:00, Segher Boessenkool
> wrote:
>> On Mon, Jun 17, 2019 at 10:51:49AM +0200, Richard Biener wrote:
>>> On Mon, 17 Jun 2019, Kewen.Lin wrote:
>>>
>>>> Hi Segher and Bi
on 2019/6/17 下午9:44, Richard Biener wrote:
> On Mon, 17 Jun 2019, Kewen.Lin wrote:
>
>> on 2019/6/17 下午8:08, Richard Biener wrote:
>>> On June 17, 2019 11:59:30 AM GMT+02:00, Segher Boessenkool
>>> wrote:
>>>> On Mon, Jun 17, 2019 at 10:51:49AM +0200,
Hi all,
This is the following patch after
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00910.html
Main steps:
1) Identify the doloop cmp type iv use and record its bind_cand (explain it
later).
2) Set zero cost for pairs between this use and any iv cand.
3) IV cand set selecting algorith
Hi Segher,
> On Wed, Jun 19, 2019 at 07:47:34PM +0800, Kewen.Lin wrote:
>> +/* Return true if count register for branch is supported. */
>> +
>> +static bool
>> +rs6000_have_count_reg_decr_p ()
>> +{
>> + return flag_branch_on_count_reg;
>>
Hi,
Sorry, the previous patch is incomplete.
New one attached. Sorry for inconvenience.
on 2019/6/20 下午8:08, Kewen.Lin wrote:
> Hi Segher,
>
>> On Wed, Jun 19, 2019 at 07:47:34PM +0800, Kewen.Lin wrote:
>>> +/* Return true if count register for branch is supported. */
&
Hi Lijia,
on 2019/6/24 下午2:00, Li Jia He wrote:
> Hi,
>
> From PowerPC ISA3.0, the description of `maddld RT, RA.RB, RC` is as follows:
> 64-bit RA and RB are multiplied and then the RC is signed extend to 128 bits,
> and add them together.
>
> We only apply it to 64-bit mode (DI) when implement
on 2019/6/24 下午3:19, Segher Boessenkool wrote:
> On Mon, Jun 24, 2019 at 02:45:09PM +0800, Kewen.Lin wrote:
>> on 2019/6/24 下午2:00, Li Jia He wrote:
>>> -#define TARGET_MADDLD (TARGET_MODULO && TARGET_POWERPC64)
>>> +#define TARGET_MADDLD TARGET_MO
on 2019/6/24 下午3:43, Kewen.Lin wrote:
> on 2019/6/24 下午3:19, Segher Boessenkool wrote:
>> On Mon, Jun 24, 2019 at 02:45:09PM +0800, Kewen.Lin wrote:
>>> on 2019/6/24 下午2:00, Li Jia He wrote:
>>>> -#define TARGET_MADDLD (TARGET_MODULO && TARGET_
Hi Segher,
on 2019/6/24 下午4:02, Segher Boessenkool wrote:
> Hi Kewen,
>
> On Mon, Jun 24, 2019 at 03:43:26PM +0800, Kewen.Lin wrote:
>> on 2019/6/24 下午3:19, Segher Boessenkool wrote:
>>> Newer ISAs require 64-bit to be implemented. There are no optional
>>>
Hi Segher,
on 2019/7/25 下午9:49, Segher Boessenkool wrote:
> Hi Kewen,
>
> On Tue, Jul 23, 2019 at 02:28:28PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/altivec.md
>> +++ b/gcc/config/rs6000/altivec.md
>> @@ -1666,6 +1666,60 @@
>>"vrl %0,%1,
Hi Segher,
You can just ignore the previous version and review the current
with one comment change and "=" line move.
Sorry for the inconvenience.
Thanks,
Kewen
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index b6a22d9010c..217c7afdf17 100644
--- a/gcc/config/rs6000
Hi Segher,
Sorry for the late, I've addressed your comments in the attached patch.
Some points:
1) Remove explict AND part.
2) Rename predicate name to vint_reg_or_vint_const.
3) Split test cases into altivec and power8.
As to the predicate name and usage, I checked the current vector shift
Hi Segher,
on 2019/8/4 上午4:52, Segher Boessenkool wrote:
> Hi!
>
> I somehow lost track of this email, sorry.
>
> On Fri, Aug 02, 2019 at 04:59:44PM +0800, Kewen.Lin wrote:
>> As to the predicate name and usage, I checked the current vector shifts,
>> they don&#
Hi Segher,
on 2019/8/6 上午5:21, Segher Boessenkool wrote:
> On Mon, Aug 05, 2019 at 11:41:41AM +0800, Kewen.Lin wrote:
>> on 2019/8/4 上午4:52, Segher Boessenkool wrote:
>>> On Fri, Aug 02, 2019 at 04:59:44PM +0800, Kewen.Lin wrote:
> There are two cases: either all elements ar
Hi!
Comparing to the previous versions of implementation mainly based on the
existing IV cands but zeroing the related group/use cost, this new one is based
on Richard and Segher's suggestion introducing one doloop dedicated IV cand.
Some key points are listed below:
1) New field doloop_p in
Hi Bin,
Thanks for your time!
on 2019/8/21 下午8:32, Bin.Cheng wrote:
> On Wed, Aug 14, 2019 at 3:23 PM Kewen.Lin wrote:
>>
>> Hi!
>>
>> Comparing to the previous versions of implementation mainly based on the
>> existing IV cands but zeroing the related group/us
Hi Bin,
on 2019/8/22 下午1:46, Bin.Cheng wrote:
> On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
>>
>> Hi Bin,
>>
>> Thanks for your time!
>>
>> on 2019/8/21 下午8:32, Bin.Cheng wrote:
>>> On Wed, Aug 14, 2019 at 3:23 PM Kewen.Lin wrote:
>>&g
Hi Bin
on 2019/8/23 上午10:19, Bin.Cheng wrote:
> On Thu, Aug 22, 2019 at 3:09 PM Kewen.Lin wrote:
>>
>> Hi Bin,
>>
>> on 2019/8/22 下午1:46, Bin.Cheng wrote:
>>> On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
>>>>
>>>> Hi Bin,
&
Hi Bin,
on 2019/8/23 下午5:43, Bin.Cheng wrote:
> On Fri, Aug 23, 2019 at 4:27 PM Kewen.Lin wrote:
>>
>> Hi Bin
>>
>> on 2019/8/23 上午10:19, Bin.Cheng wrote:
>>> On Thu, Aug 22, 2019 at 3:09 PM Kewen.Lin wrote:
>>>>
>>>> Hi Bin,
>>
e-ssa/pr32044.c: Likewise.
on 2019/8/23 下午6:18, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Aug 23, 2019 at 05:43:32PM +0800, Bin.Cheng wrote:
>> On Fri, Aug 23, 2019 at 4:27 PM Kewen.Lin wrote:
>> Not sure if non-ivopts parts are already approved? If so, the patch
&g
on 2019/9/12 下午4:14, Richard Biener wrote:
> On Wed, 11 Sep 2019, Kewen.Lin wrote:
>
>> Hi,
>>
>> Sorry for the late update. I've updated the words of target hooks part.
>>
>> Could someone help to review it? Thanks in advance!
>>
>> B
Hi all,
As PR62147, for some cases loop iv analysis is unable to identify one loop is
finite even if the loop is actually finite and we have known it in middle-end.
It will prevent doloop_optimize and end up with worse codes.
This patch is going to leverage existing middle-end function finite_lo
Hi Richard,
Thanks a lot for review comments.
on 2019/6/25 下午3:23, Richard Biener wrote:
> On Tue, 25 Jun 2019, Kewen.Lin wrote:
>
>> Hi all,
>>
>>
>> It's based on two observations:
>> 1) the loop structure for one specific loop is shared between mid
Hi Jeff,
on 2019/6/26 上午5:49, Jeff Law wrote:
> On 6/25/19 3:41 AM, Kewen.Lin wrote:
>> Hi Richard,
>>
>> Thanks a lot for review comments.
>>
>> on 2019/6/25 下午3:23, Richard Biener wrote:
>>> On Tue, 25 Jun 2019, Kewen.Lin wrote:
>>>
>>
Hi all,
Gentle ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00966.html
on 2019/6/11 上午10:46, Kewen.Lin wrote:
> Hi,
>
> Gentle ping again. Thanks!
>
> Kewen
>
> on 2019/5/21 上午10:02, Kewen.Lin wrote:
>> Hi,
>>
>> Gentle ping again
te = NULL_RTX;
if (dump_file)
on 2019/6/26 上午11:45, Kewen.Lin wrote:
> Hi Jeff,
>
> on 2019/6/26 上午5:49, Jeff Law wrote:
>> On 6/25/19 3:41 AM, Kewen.Lin wrote:
>>> Hi Richard,
>>>
>>> Thanks a lot for review comments.
>>>
>>> on 2
Hi Richard,
Thanks very much for reviewing my patch. I'll update it as your comments.
Before sending the next version, I've several questions embedded for further
check.
on 2019/7/2 下午8:43, Richard Biener wrote:
> On Wed, 20 Mar 2019, Kewen.Lin wrote:
>
>> +/* { dg-re
Hi Richard,
Thanks a lot for your review and reply, I've updated the patch accordingly.
Main changes compared to previous one:
- Consider SVE (poly_int) on bit_field_ref size/offset.
- Filter valid candidates with sbitmap first.
- Support multiple modes (TODO 1).
- Test cases: add SSE2 su
Hi Segher,
on 2019/7/9 上午12:32, Segher Boessenkool wrote:
> Hi Kewen,
>
> On Mon, Jul 08, 2019 at 04:07:00PM +0800, Kewen.Lin wrote:
>> gcc/ChangeLog
>
> (You have trailing spaces in the changelog, fwiw).
>
Thanks for catching!
>> --- /dev/null
>> +++ b/g
Hi all,
I'd like to gentle ping the below patch:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01225.html
The previous version for more context/background:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01126.html
Thanks a lot in advance!
on 2019/6/20 下午8:16, Kewen.Lin wrote:
> Hi,
&g
Hi all,
6: NOTE_INSN_BASIC_BLOCK 2
12: r135:CC=cmp(r122:DI,0)
13: pc={(r135:CC!=0)?L52:pc}
REG_DEAD r135:CC
REG_BR_PROB 1041558836
31: L31:
17: NOTE_INSN_BASIC_BLOCK 3
The above RTL sequence is from pass doloop dumping with -fdump-rtl-all-slim, I
misunders
Hi Richard,
on 2019/7/11 上午3:30, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi all,
>> Is it a reasonable patch? If yes, is it ok for trunk?
>
> It looks really useful, but IMO we should either emit the hint for all
> end-of-block insns with a surpri
Hi Richard,
on 2019/7/10 下午7:50, Richard Biener wrote:
> On Mon, 8 Jul 2019, Kewen.Lin wrote:
>
>
> + tree rhs = gimple_assign_rhs1 (oe1def);
> + tree vec = TREE_OPERAND (rhs, 0);
> + tree vec_type = TREE_TYPE (vec);
> +
> + if (TREE_CODE (vec) != SS
Hi Richard,
on 2019/7/11 下午4:51, Richard Sandiford wrote:
> Kewen.Lin writes:
>>
>> - if (flags & TDF_BLOCKS)
>
> I think we still need an if here, but with the condition instead being:
>
>cfun->curr_properties & PROP_cfg
>
>> +
on 2019/7/11 下午9:55, Richard Sandiford wrote:
> Kewen.Lin writes:
>> + /* Emit a hint if the fallthrough target of current basic block
>> +isn't the one placed right next. */
>> + else if (
Hi Richard,
on 2019/7/12 下午8:11, Richard Biener wrote:
> On Wed, 10 Jul 2019, Kewen.Lin wrote:
>
>> Hi all,
>>
>> I'd like to gentle ping the below patch:
>> https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01225.html
>>
>> The previous version for mor
Hi all,
In match.pd and expmed.c, we have some codes to transform lrotate to
rrotate if rotation count is const. But they don't consider the target
whether supports the rrotate. It leads to some suboptimal generated
code since some optimization can't get expected result by querying
target optab
Hi Jakub,
on 2019/7/15 下午4:59, Jakub Jelinek wrote:
> On Mon, Jul 15, 2019 at 04:50:13PM +0800, Kewen.Lin wrote:
>> In match.pd and expmed.c, we have some codes to transform lrotate to
>> rrotate if rotation count is const. But they don't consider the target
>> whether
Hi all,
Based on the previous comments (thank you!), I tried to update the
handling in expander and vectorizer. Middle-end optimizes lrotate
with const rotation count to rrotate all the time, it makes vectorizer
fail to vectorize if rrotate isn't supported on the target. We can at
least teach i
on 2019/7/16 下午4:45, Kewen.Lin wrote:
> Hi all,
>
> Based on the previous comments (thank you!), I tried to update the
> handling in expander and vectorizer. Middle-end optimizes lrotate
> with const rotation count to rrotate all the time, it makes vectorizer
> fail to vectoriz
on 2019/7/17 下午4:42, Jakub Jelinek wrote:
> On Wed, Jul 17, 2019 at 04:32:15PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/vector.md
>> +++ b/gcc/config/rs6000/vector.md
>> @@ -1260,6 +1260,32 @@
>>"VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
>>
Hi Segher,
on 2019/7/17 下午9:40, Segher Boessenkool wrote:
> Hi Kewen,
>
> On Wed, Jul 17, 2019 at 04:32:15PM +0800, Kewen.Lin wrote:
>> Regression testing just launched, is it OK for trunk if it's bootstrapped
>> and regresstested on powerpc64le-unknown-linux-gn
on 2019/7/17 下午6:37, Richard Biener wrote:
> On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin wrote:
>>
>> Hi all,
>>
>> Based on the previous comments (thank you!), I tried to update the
>> handling in expander and vectorizer. Middle-end optimizes lrotate
>> w
on 2019/7/19 上午3:48, Segher Boessenkool wrote:
> On Thu, Jul 18, 2019 at 01:44:36PM +0800, Kewen.Lin wrote:
>> Hi Segher,
>>
>> on 2019/7/17 下午9:40, Segher Boessenkool wrote:
>>> Hi Kewen,
>>>
>>> On Wed, Jul 17, 2019 at 04:32:15PM +0800, Kewen.Lin
Hi Bin,
on 2019/7/21 上午11:07, Bin.Cheng wrote:
> On Wed, Jun 19, 2019 at 7:47 PM Kewen.Lin wrote:
>>
>> Hi all,
>>
>> This is the following patch after
>> https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00910.html
>>
>> Main steps:
>> 1)
Hi Segher,
on 2019/7/22 下午2:26, Segher Boessenkool wrote:
> Hi!
>
> (Maybe I am missing half of the discussion -- sorry if so).
>
> I think we should have a new iv for just the doloop (which can have the
> same starting value and step and type as another iv).
>
> Has this been considered?
>
>
on 2019/7/22 下午3:18, Richard Biener wrote:
> On Mon, 22 Jul 2019, Segher Boessenkool wrote:
>
>> Hi!
>>
>> (Maybe I am missing half of the discussion -- sorry if so).
>>
>> I think we should have a new iv for just the doloop (which can have the
>> same starting value and step and type as another i
Hi Segher,
on 2019/7/23 上午5:43, Segher Boessenkool wrote:
> On Mon, Jul 22, 2019 at 09:18:10AM +0200, Richard Biener wrote:
>> On Mon, 22 Jul 2019, Segher Boessenkool wrote:
>>
>>> Hi!
>>>
>>> (Maybe I am missing half of the discussion -- sorry if so).
>>>
>>> I think we should have a new iv for j
Hi Bin,
This patch follows your suggestion, to avoid use infinite cost iv cand to
rewrite.
In order to allow other IV cands to be considered, zeroing the iv cand cost if
its users are only doloop uses. (See the typical case in previous reply.)
Could you please have a look? Thanks in advance!
arget/powerpc/vec_rotate-1.c: New test.
* gcc.target/powerpc/vec_rotate-2.c: New test.
on 2019/7/19 下午11:06, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jul 19, 2019 at 10:21:06AM +0800, Kewen.Lin wrote:
>> on 2019/7/19 上午3:48, Segher Boessenkool wrote:
>>> On Thu, Jul
Hi,
As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
when we meet some code pattern like:
V1[0] + V1[1] + ... + V1[k] + V2[0] + ... + V2[k] + ... Vn[k]
// V1...Vn of VECTOR_TYPE
We can teach reassoc to transform it to:
Vs = (V1 + V2 + ... + Vn)
Vs[0] + Vs[1] + ..
on 2019/3/8 下午6:57, Richard Biener wrote:
> On Fri, Mar 8, 2019 at 2:40 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
>> when we meet some code pattern like:
>>
>>V1[0] + V1[1] + ... + V1[k]
on 2019/3/11 下午6:24, Richard Biener wrote:
> On Mon, 11 Mar 2019, Kewen.Lin wrote:
>
>> on 2019/3/8 下午6:57, Richard Biener wrote:
>>> On Fri, Mar 8, 2019 at 2:40 AM Kewen.Lin wrote:
>>>>
>>>> Hi,
>>>>
>>>> As PR88497 (https:
,13 @@ reassociate_bb (basic_block bb)
optimize_ops_list (rhs_code, &ops);
}
+ if (undistribute_bitref_for_vector (rhs_code, &ops,
+ loop_containing_stmt (stmt)))
+ {
+
on 2019/3/12 下午11:22, Bill Schmidt wrote:
> On 3/12/19 9:29 AM, Bill Schmidt wrote:
>> On 3/12/19 7:57 AM, Kewen.Lin wrote:
>>> Hi,
>>>
>>> As the comments from Richard and Segher (Thanks!), I've made some
>>> changes by adding some checks a
Hi,
Please refer to below link for previous threads.
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00348.html
Comparing to patch v2, I've moved up the vector operation target
check upward together with vector type target check. Besides, I
ran bootstrap and regtest on powerpc64-linux-gnu (BE), u
Hi,
Gentle ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00966.html
Thanks!
on 2019/3/19 上午11:14, Kewen.Lin wrote:
> Hi,
>
> Please refer to below link for previous threads.
> https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00348.html
>
> Comparing to pa
Hi all,
As PR80791 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791, on
some targets which support low-overhead loop, the related compare
type ivs use is possible to become dead and removed eventually.
However, the current ivopt cost modeling doesn't consider this
possible elimination, it leads
24, 2019 at 04:41:01PM +0800, Kewen.Lin wrote:
>> gcc/ChangeLog
>
> Not a review, just ChangeLog nits.
>
>> 2019-04-24 Kewen Lin
>>
>> PR middle-end/80791
>> * target.def (predict_doloop_p): New.
>> * targhooks.h (defau
Hi Segher,
Thanks a lot for your comments!
on 2019/4/25 下午8:16, Segher Boessenkool wrote:
> Does it create worse code now? What we have before your patch isn't
> so super either (it has an sldi in the loop, it has two mtctr too).
> Maybe you can show the generated code?
It's a good question!
on 2019/4/26 下午3:16, Richard Biener wrote:
> On Fri, 26 Apr 2019, Kewen.Lin wrote:
>
>> I was thinking whether this zero cost change just exposed
>> an existing problem, then this kind of check should be for all
>> cases not only for zero cost use, similar to
>>
Hi Bin,
Sorry for late response (just back from vacation).
Thanks very much for your comments.
on 2019/4/27 上午11:20, Bin.Cheng wrote:
> For such non-trivial patch, we can improve review process by splitting
> to smaller patches which can be reviewed/approved independently.
Good idea! I'll split
on 2019/4/27 上午12:59, Segher Boessenkool wrote:
> On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote:
>> on 2019/4/26 下午3:16, Richard Biener wrote:
>>> We should think about possible ways of encoding doloop at IVOPTs
>>> time rather than trying to re-analyz
on 2019/4/27 上午11:44, Bin.Cheng wrote:
> On Fri, Apr 26, 2019 at 2:44 PM Kewen.Lin wrote:
>> +
>> + /* zero cost use makes it easier to select memory based iv cand
>> + for replacement of non memory based iv and its use. But if
>> + the setup se
on 2019/5/5 下午12:04, Bin.Cheng wrote:
> On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
>>>> + /* Some compare iv_use is probably useless once the doloop optimization
>>>> + performs. */
>>>> + if (tailor_cmp_p)
>>>> +tailor_cmp_us
Hi,
I'd like to gentle ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00966.html
OK for trunk now?
Thanks!
on 2019/3/20 上午11:14, Kewen.Lin wrote:
> Hi,
>
> Please refer to below link for previous threads.
> https://gcc.gnu.org/ml/gcc-patches/2019
on 2019/5/6 上午9:50, Bin.Cheng wrote:
> On Sun, May 5, 2019 at 2:02 PM Kewen.Lin wrote:
>>
>> To decrease the cost isn't workable for this case, it make the original
>> iv cand is preferred more and over the other iv cand for memory iv use,
>> then the desirab
on 2019/5/14 下午3:18, Richard Biener wrote:
> Hum. The function is somewhat of a hack, trying to produce
> "reasonable" DECL_RTL, exposing it in expr.[ch] with this
> name is eventually misleading. Also you fail to "outline"
> the most important part:
>
> FOR_EACH_VEC_ELT (decl_rtl_to_reset,
on 2019/5/14 下午3:24, Richard Biener wrote:>
> Most of the rs6000 target hook checks look general
> (can we compute niter, etc.), IVOPTs would have a hard
> time adding a counter IV w/o being able to compute niters.
Do you mean to reuse them?
Yes, IVOPTs has already checked niter. At the initial
on 2019/5/15 上午10:40, Bin.Cheng wrote:
> I wonder if you can factor out generic part into GIMPLE and leave
> target hook as specific as possible?
>
Good suggestion! Yes, most of the checks are common as you
pointed out. I hope the other targets won't have more
customization needs excepting for
on 2019/5/14 下午3:26, Richard Biener wrote:
> On Tue, May 14, 2019 at 5:10 AM wrote:
>>
>> From: Kewen Lin
>>
>> Previous version link for background:
>> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>>
>> Firstly, it's to call predict_doloop_p hook to check this
>> loop will be transfo
on 2019/5/15 上午11:34, Kewen.Lin wrote:
>
> on 2019/5/15 上午10:40, Bin.Cheng wrote:
>> I wonder if you can factor out generic part into GIMPLE and leave
>> target hook as specific as possible?
>>
>
> Good suggestion! Yes, most of the checks are common as you
&g
on 2019/5/15 上午10:11, Kewen.Lin wrote:
>
> on 2019/5/14 下午3:18, Richard Biener wrote:
>> Hum. The function is somewhat of a hack, trying to produce
>> "reasonable" DECL_RTL, exposing it in expr.[ch] with this
>> name is eventually misleading. Also you fail
on 2019/5/15 下午4:50, Bin.Cheng wrote:
> On Wed, May 15, 2019 at 4:38 PM Kewen.Lin wrote:
>>
>> on 2019/5/15 上午10:11, Kewen.Lin wrote:
>>>
>>> on 2019/5/14 下午3:18, Richard Biener wrote:
>>>> Hum. The function is somewhat of a hack, trying to produce
&g
on 2019/5/15 下午4:47, Richard Biener wrote:
> On Wed, 15 May 2019, Kewen.Lin wrote:
>
>> on 2019/5/14 下午3:26, Richard Biener wrote:
>>> On Tue, May 14, 2019 at 5:10 AM wrote:
>>>>
>>>> From: Kewen Lin
>>>>
>>>> Previous version
on 2019/5/17 下午1:30, Kugan Vivekanandarajah wrote:
> Hi,
>
> On Fri, 17 May 2019 at 13:37, wrote:
>>
>> From: Kewen Lin
>>
>> +/* Check whether number of iteration computation is too costly for doloop
>> + transformation. It expands the gimple sequence to equivalent RTL insn
>> + sequence,
Hi Segher,
on 2019/5/17 下午2:49, Segher Boessenkool wrote:
> Hi Kewen,
>
> On Thu, May 16, 2019 at 10:35:30PM -0500, li...@linux.ibm.com wrote:
>> 2) For the other part of target invalid stmt check, as the
>> hook invalid_within_doloop grep data shows, no all targets
>> need to check whether inval
Hi,
Gentle ping again. Thanks!
Kewen
on 2019/5/5 下午2:15, Kewen.Lin wrote:
> Hi,
>
> I'd like to gentle ping for this patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00966.html
>
> OK for trunk now?
>
> Thanks!
>
> on 2019/3/20 上午11:14, Kewen.Lin
on 2019/5/20 下午5:28, Richard Biener wrote:
> On Thu, 16 May 2019, li...@linux.ibm.com wrote:
>
>> From: Kewen Lin
>>
>> Hi,
>>
>> Previous version link:
>> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00654.html
>>
>> Comparing with the previous version, I moved the generic
>> parts of rs6000 ta
on 2019/5/20 下午5:28, Richard Biener wrote:
> On Thu, 16 May 2019, li...@linux.ibm.com wrote:
>
>> From: Kewen Lin
>>
>> Hi,
>>
>> Previous version link:
>> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00654.html
>>
>> Comparing with the previous version, I moved the generic
>> parts of rs6000 ta
on 2019/5/20 下午10:43, Jeff Law wrote:
> On 5/20/19 4:24 AM, Segher Boessenkool wrote:
>> Let me try to answer a bit here...
>>
>> On Mon, May 20, 2019 at 11:28:26AM +0200, Richard Biener wrote:
>>> On Thu, 16 May 2019, li...@linux.ibm.com wrote:
>>
>>> So the better way would be to expose that via
on 2019/5/21 上午12:37, Segher Boessenkool wrote:
> On Mon, May 20, 2019 at 08:43:59AM -0600, Jeff Law wrote:
>>> I think we should have two hooks: one is called with the struct loop as
>>> parameter; and the other is called for every statement in the loop, if
>>> the hook isn't null anyway. Or perh
Hi,
this adds myself to MAINTAINERS in the Write After Approval section.
Committed to trunk as r267965.
---
Index: ChangeLog
===
--- ChangeLog (revision 267964)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2019-01-16 Kewen Li
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87306, it's older POWER
hardware specific test case issue. On POWER7 and earlier, we implicitly
set flag -mno-allow-movmisalign which disables vectorization when to
vectorize the code requires that misaligned loads and stores. For POWER8
and uppe
Hi,
On target rs6000, for all types, use of vec_ld/vec_st historically permits the
dereferenced pointer to be of a scalar type or the corresponding vector type.
But for vector unsigned/signed long long and double, we have an omission in our
table for vec_ld/vec_st.
Ok for trunk, and eventual
on 2019/1/19 上午9:04, Segher Boessenkool wrote:
> On Fri, Jan 18, 2019 at 11:15:12PM +0100, Jakub Jelinek wrote:
>> On Wed, Jan 16, 2019 at 10:08:46PM +0800, Kewen.Lin wrote:
>>> * gcc.target/powerpc/altivec_vld_vst_addr.c: New test.
>>
>> This test fails on
on 2023/5/30 17:26, juzhe.zh...@rivai.ai wrote:
> Ok.
>
> It seems that for this conditions:
>
> + /* If we're vectorizing a loop that uses length "controls" and
> + can iterate more than once, we apply decrementing IV approach
> + in loop control. */
> + if (LOOP_VINFO_CAN_USE_PARTIAL
> Hi, Richi.
>
>>> Note with SELECT_VL all bets will be off since as I understand the
>>> value it gives can vary from iteration to iteration (but we know
>>> a lower and maybe an upper bound?)
> Yes, in RVV side, the SELECT_VL output can be in range of [ceil(avl/2),
> vlmax],
> can be any value
Hi Andreas,
on 2023/5/25 15:25, Andreas Krebbel wrote:
> On 3/20/23 07:33, Kewen.Lin wrote:
>> Hi,
>>
>> One of my workmates found there is a warning like:
>>
>> libgcc/config/rs6000/morestack.S:402: Warning: ignoring
>> incorrect section type for
Hi Segher,
on 2023/5/25 19:22, Segher Boessenkool wrote:
> Hi!
>
> On Thu, May 25, 2023 at 07:05:55AM -0300, Alexandre Oliva wrote:
>> On May 25, 2023, "Kewen.Lin" wrote:
>>> So both lp64 and ilp32 have the same count, could we merge it and
>>> remo
Hi Carl,
on 2023/5/25 23:59, Carl Love wrote:
> Peter, Kewen:
>
> On Thu, 2023-05-25 at 13:28 +0800, Kewen.Lin wrote:
>> on 2023/5/24 23:20, Carl Love wrote:
>>> On Wed, 2023-05-24 at 13:32 +0800, Kewen.Lin wrote:
>>>> on 2023/5/24 06:30, Peter Bergner wrote:
Hi Juzhe,
on 2023/6/1 08:31, juzhe.zh...@rivai.ai wrote:
> Bootstrapped and Regression on X86 no surprise different.
>
> Looking forward Kewen's test report for this patch.
>
This patch can be bootstrapped and regress-tested on
powerpc64-linux-gnu P9 and powerpc64le-linux-gnu P9/P10.
Also SPEC
Hi,
on 2023/6/1 13:00, juzhe.zh...@rivai.ai wrote:
> This patch is no difference from V2.
I support this patch based on the testing and SPEC2017 evaluation
results on Power (see my comments on patch v2).
> Just add PR tree-optimization/109971 as Kewen's suggested.
Thanks for adding that, I was
Hi Carl,
on 2023/6/2 04:01, Carl Love wrote:
> Kewen, Segher, Peter:
>
> The following patch is a redo of the previous "rs6000: Fix
> __builtin_vec_xst_trunc definition" patch.
>
> This patch fixes the argument in the two builtin definitions
> __builtin_altivec_tr_stxvrwx and __builtin_altivec
on 2023/6/2 04:01, Carl Love wrote:
> On Wed, 2023-05-31 at 12:59 -0500, Peter Bergner wrote:
>> On 5/22/23 4:04 AM, Kewen.Lin wrote:
>>> on 2023/5/11 02:06, Carl Love via Gcc-patches wrote:
>>>> @@ -3161,12 +3161,15 @@
>>>>void __builtin_altivec_tr_s
501 - 600 of 1615 matches
Mail list logo
