[PATCH 2/2] aarch64 back-end changes

From: Kugan Vivekanandarajah gcc/ChangeLog: 2019-05-15 Kugan Vivekanandarajah PR target/88834 * config/aarch64/aarch64.c (aarch64_classify_address): Relax allow_reg_index_p. gcc/testsuite/ChangeLog: 2019-05-15 Kugan Vivekanandarajah PR target/88834

Re: [PATCH v2 2/3] Add predict_doloop_p target hook

I wonder if you can factor out generic part into GIMPLE and leave target hook as specific as possible? On Tue, May 14, 2019 at 11:10 AM wrote: > > From: Kewen Lin > > Previous version link for background: > https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html > > This hook is to predict whet

Re: [PATCH v2 2/3] Add predict_doloop_p target hook

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

New Documents For(gcc-patches@gcc.gnu.org)Your Shipment (Shipping SF Electronic Invoice Notification)

\0Ae6Cv84�7AN30�1F�D0[A2b37�1A `A8Y7D gcc-patches@gcc.gnu.org a1F�22`A8�09bE9�7AN30�1F�D0N3A`A8cD0O9Bv84e36m3Eg0DRA1002 `A8u33�F7v84u35[50SD1y68]F2b10R9F_00Q77�01SD1y68�E6`C5Y82N0B�1A SD1y68NE3x01�1A019093877133873SD1y68SF7x01�1A5123338323SD1y68�D1�9D�1A639.9Q43 S05T2Bv84�D0S55SF7�1A `A8

Re: [PATCH v2 2/3] Add predict_doloop_p target hook

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

[PATCH] Refactor away an obsolete is_unsigned distinction in is_value_included_in

Hi! This is just a clean-up. During the course of past refactorings, the then and else branches of `if (is_unsigned)` in is_value_included_in() became semantically equivalent and almost textually identical. This patch removes the conditional altogether. Regtested and bootstrapped with `BOOT_CFL

[PATCH PR57534]Support strength reduction for MEM_REF in slur

Hi, As noted in PR57534 comment #33, SLSR currently doesn't strength reduce memory references in reported cases, which conflicts with its comment at the beginning of file. The main reason is in functions slsr_process_ref and restructure_reference which rejects MEM_REF by handled_compoenent_p in th

Re: [PATCH v2 3/3] Consider doloop cmp use in ivopts

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

Re: [PATCH v2 2/3] Add predict_doloop_p target hook

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 > pointed out. I hope the other targets

[PATCH GCC]refactor process of copy and cast in slsr

Hi, I noticed that slsr_process_copy and slsr_process_cast are almost identical and called only once. This patch refactor the two functions into one. For copies, it also passes lhs' type to creation of new cand assuming that lhs, rhs and base_cand have the same/compatible type. I will keep an eye

[PATCH GCC]Correct cand_chain and stmt_cand_map for copy/cast

Hi, I noticed that cand_chain (first_interp/next_interp) is not maintained correctly in slsr_process_copy/slsr_process_cast (now slsr_process_copycast). This one fixes the issue, as well as records the "first" cand in stmt_cand_map. Hi Bill, is this correct or I misunderstood the code? Bootstrap

Re: [PATCH v2 2/3] Add predict_doloop_p target hook

On Wed, May 15, 2019 at 1:20 PM Kewen.Lin wrote: > > 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

Re: New .md construct: define_insn_and_rewrite

Eric Botcazou writes: >> This patch therefore adds a new construct called define_insn_and_rewrite. >> It's basically a define_insn_and_split with an implicit split pattern, >> obtained by copying the insn pattern and replacing match_operands with >> match_dups and match_operators with match_op_dup

Re: [PATCH 1/2] Add support for IVOPT

Thanks for doing this. kugan.vivekanandara...@linaro.org writes: > From: Kugan Vivekanandarajah > > gcc/ChangeLog: > > 2019-05-15 Kugan Vivekanandarajah > > PR target/88834 > * tree-ssa-loop-ivopts.c (get_mem_type_for_internal_fn): Handle > IFN_MASK_LOAD_LANES and IFN_MASK_ST

<    1   2