Re: [RFC] Try vector as a new representation for vector masks

2015-09-18 16:40 GMT+03:00 Ilya Enkovich <enkovich@gmail.com>: > 2015-09-18 15:22 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> >> I was thinking about targets not supporting generating vec >> (of whatever mode) from a comparison directly but only

Re: [RFC] Try vector as a new representation for vector masks

2015-09-18 19:50 GMT+03:00 Richard Henderson <r...@redhat.com>: > On 09/18/2015 06:21 AM, Ilya Enkovich wrote: >>>> +machine_mode >>>> +default_get_mask_mode (unsigned nunits, unsigned vector_size) >>>> +{ >>>> + unsigned elem_si

Re: [RFC] Try vector as a new representation for vector masks

2015-09-17 20:35 GMT+03:00 Richard Henderson <r...@redhat.com>: > On 09/15/2015 06:52 AM, Ilya Enkovich wrote: >> I made a step forward forcing vector comparisons have a mask (vec) >> result and disabling bool patterns in case vector comparison is supported by >> targe

Re: [RFC] Try vector as a new representation for vector masks

2015-09-18 15:29 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Tue, Sep 15, 2015 at 3:52 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> On 08 Sep 15:37, Ilya Enkovich wrote: >>> 2015-09-04 23:42 GMT+03:00 Jeff Law <l...@redhat.com>: >>

Re: [RFC] Try vector as a new representation for vector masks

2015-09-18 15:22 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Thu, Sep 3, 2015 at 3:57 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> 2015-09-03 15:11 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>> On Thu, Sep 3, 2015

Re: [RFC] Masking vectorized loops with bound not aligned to VF.

t; right now is x86's AVX-512, which features per-element embedded masking >> for all instructions. The main goal for this mail is to agree on overall >> design of the feature. >> >> This approach was presented @ GNU Cauldron 2015 by Ilya Enkovich [1]. >> >> Here's

Re: [PATCH, PR67405, committed] Avoid NULL pointer dereference

2015-09-13 16:36 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Mon, Sep 7, 2015 at 2:39 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> 2015-09-02 15:35 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>> >>> DECL_FIELD_BIT_

Re: [PATCH, PR67405, committed] Avoid NULL pointer dereference

2015-09-15 13:32 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Tue, Sep 15, 2015 at 11:28 AM, Ilya Enkovich <enkovich@gmail.com> > wrote: >> 2015-09-13 16:36 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>> On Mon, Sep 7, 2

Re: [RFC] Try vector as a new representation for vector masks

On 08 Sep 15:37, Ilya Enkovich wrote: > 2015-09-04 23:42 GMT+03:00 Jeff Law <l...@redhat.com>: > > > > So do we have enough confidence in this representation that we want to go > > ahead and commit to it? > > I think new representation fits nice mostly. The

Re: [RFC, PR target/65105] Use vector instructions for scalar 64bit computations on 32bit target

On 09 Sep 10:20, Uros Bizjak wrote: > On Wed, Sep 9, 2015 at 10:12 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > > On Tue, Sep 8, 2015 at 5:49 PM, Ilya Enkovich <enkovich@gmail.com> > > wrote: > > > > Please depend new changes to insn patterns to TAR

Re: [RFC] Try vector as a new representation for vector masks

2015-09-04 23:42 GMT+03:00 Jeff Law <l...@redhat.com>: > On 09/01/2015 07:08 AM, Ilya Enkovich wrote: >> >> On 27 Aug 09:55, Richard Biener wrote: >>> >>> I suggest you try modifying those parts first according to this >>> scheme that will most

Re: [RFC, PR target/65105] Use vector instructions for scalar 64bit computations on 32bit target

On 21 Aug 10:38, Jeff Law wrote: > On 08/21/2015 07:44 AM, Ilya Enkovich wrote: > >>Our of curiosity, what does LLVM do here in terms of costing > >>models? > > > >Unfortunately I have no idea where and how LLVM does this > >optimization. Will try to

Re: [PATCH, PR67405, committed] Avoid NULL pointer dereference

2015-09-02 15:35 GMT+03:00 Richard Biener : > > DECL_FIELD_BIT_OFFSET should be never NULL. Whoever created that > FIELD_DECL created an invalid one. > > Richard. > layout_class_type doesn't place fields with no type and thus we have nothing for DECL_FIELD_BIT_OFFSET.

Re: [RFC] Try vector as a new representation for vector masks

2015-09-03 15:11 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Thu, Sep 3, 2015 at 2:03 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> Adding CCs. >> >> 2015-09-03 15:03 GMT+03:00 Ilya Enkovich <enkovich@gmail.com>: >&g

Re: [RFC] Try vector as a new representation for vector masks

Adding CCs. 2015-09-03 15:03 GMT+03:00 Ilya Enkovich <enkovich@gmail.com>: > 2015-09-01 17:25 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> On Tue, Sep 1, 2015 at 3:08 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >>> On 27 Aug 09:55, Richa

Re: [PATCH, PR67405, committed] Avoid NULL pointer dereference

2015-09-02 15:35 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Tue, Sep 1, 2015 at 5:03 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> Hi, >> >> This fixes an ICE by adding a NULL check. Bootstrapped and regtested for >> x86_64-unkn

[PATCH, PR67405, committed] Avoid NULL pointer dereference

Hi, This fixes an ICE by adding a NULL check. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Does this need to be ported to gcc-5-branch? Thanks, Ilya -- gcc/ 2015-09-01 Ilya Enkovich <enkovich@gmail.com> PR target/67405 * tree-

[RFC] Try vector as a new representation for vector masks

On 27 Aug 09:55, Richard Biener wrote: > On Wed, Aug 26, 2015 at 5:51 PM, Ilya Enkovich <enkovich@gmail.com> wrote: > > > > Yes, I want to try it. But getting rid of bool patterns would mean > > support for all targets currently supporting vec_cond. Would it be OK

Re: [Scalar masks 2/x] Use bool masks in if-conversion

2015-08-26 17:56 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Wed, Aug 26, 2015 at 4:38 PM, Ilya Enkovich enkovich@gmail.com wrote: 2015-08-26 16:02 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Fri, Aug 21, 2015 at 2:17 PM, Ilya Enkovich enkovich@gmail.com wrote

Re: [Scalar masks 2/x] Use bool masks in if-conversion

2015-08-26 0:26 GMT+03:00 Jeff Law l...@redhat.com: On 08/21/2015 06:17 AM, Ilya Enkovich wrote: Hmm, I don't see how vector masks are more difficult to operate with. There are just no instructions for that but you have to pretend you have to get code vectorized. Also according

Re: [Scalar masks 2/x] Use bool masks in if-conversion

2015-08-26 0:42 GMT+03:00 Jeff Law l...@redhat.com: On 08/21/2015 04:49 AM, Ilya Enkovich wrote: I want a work with bitmasks to be expressed in a natural way using regular integer operations. Currently all masks manipulations are emulated via vector statements (mostly using a bunch

Re: [Scalar masks 2/x] Use bool masks in if-conversion

2015-08-26 16:02 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Fri, Aug 21, 2015 at 2:17 PM, Ilya Enkovich enkovich@gmail.com wrote: 2015-08-21 14:00 GMT+03:00 Richard Biener richard.guent...@gmail.com: Hmm, I don't see how vector masks are more difficult to operate

Re: [Scalar masks 2/x] Use bool masks in if-conversion

2015-08-21 11:15 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Thu, Aug 20, 2015 at 8:46 PM, Jeff Law l...@redhat.com wrote: On 08/17/2015 10:25 AM, Ilya Enkovich wrote: Hi, This patch intoriduces a new vectorizer hook use_scalar_mask_p which affects code generated

Re: [RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.

2015-08-20 21:41 GMT+03:00 Jeff Law l...@redhat.com: On 08/17/2015 10:22 AM, Ilya Enkovich wrote: Hi, This patch starts a series introducing scalar masks support in the vectorizer. It was discussed on the recent Cauldron and changes overiew is available here: https://gcc.gnu.org/wiki

Re: [Scalar masks 2/x] Use bool masks in if-conversion

2015-08-21 14:00 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Fri, Aug 21, 2015 at 12:49 PM, Ilya Enkovich enkovich@gmail.com wrote: 2015-08-21 11:15 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Thu, Aug 20, 2015 at 8:46 PM, Jeff Law l...@redhat.com wrote: On 08/17

Re: [RFC, PR target/65105] Use vector instructions for scalar 64bit computations on 32bit target

2015-08-03 23:52 GMT+03:00 Jeff Law l...@redhat.com: On 06/19/2015 07:21 AM, Ilya Enkovich wrote: Hi, This patch tries to improve 64bit integer computations on 32bit target. This is achieved by an additional i386 target pass which searches for all conversion candidates and tries

Re: [RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.

2015-08-21 18:57 GMT+03:00 Jeff Law l...@redhat.com: On 08/21/2015 06:30 AM, Ilya Enkovich wrote: 2015-08-20 21:41 GMT+03:00 Jeff Law l...@redhat.com: 2015-08-17 Ilya Enkovich enkovich@gmail.com * expr.c (expand_expr_real_2): Support GEN_MASK_EXPR. * gimple-pretty

[Scalar masks 5/x] Bool patterns

- to avoid unsupported (for now) masks packing and unpacking, operands for cond_expr use type of a proper size and additional conversion is added if required. Thanks, Ilya -- 2015-08-17 Ilya Enkovich enkovich@gmail.com * tree-vect-patterns.c (search_type_for_mask): New

[Scalar masks 6/x] Vectorize bool statements

Hi, This patch adds vectorization for statements we can now get due to modified bool patterns. Comparison is transformed into vector comparison + GEN_MASK_EXPR. Other ops basically just get integer type. Thanks, Ilya -- 2015-08-17 Ilya Enkovich enkovich@gmail.com * tree

[Scalar masks 4/x] Vecorization factor and vectype for bool statements

Hi, This patch adopts vectorization factor and vectype computation to statements operating with boolean operands. For comparison compared values are used to estimate VF. Other bool statements don't affect VF. Thanks, Ilya -- 2015-08-18 Ilya Enkovich enkovich@gmail.com * tree

[Scalar masks 2/x] Use bool masks in if-conversion

Hi, This patch intoriduces a new vectorizer hook use_scalar_mask_p which affects code generated by if-conversion pass (and affects patterns in later patches). Thanks, Ilya -- 2015-08-17 Ilya Enkovich enkovich@gmail.com * doc/tm.texi (TARGET_VECTORIZE_USE_SCALAR_MASK_P): New

[RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.

still have several type conversion tests not being vectorized and it wasn't widely tested. That's what I'm working on now. Will be glad to any comments. Thanks, Ilya -- 2015-08-17 Ilya Enkovich enkovich@gmail.com * expr.c (expand_expr_real_2): Support GEN_MASK_EXPR. * gimple

[Scalar masks 3/x] Support scalar masks in MASK_LOAD, MASK_STORE and VEC_COND_EXPR

comments? Thanks, Ilya -- gcc/ChangeLog: 2015-08-17 Ilya Enkovich enkovich@gmail.com * internal-fn.c (expand_MASK_LOAD): Support scalar mask. (expand_MASK_STORE): Likewise. * optabs.c (get_vcond_icode): Likewise. (expand_vec_cond_expr_p): Likewise

Re: [PATCH][RTL-ifcvt] Improve conditional select ops on immediates

2015-08-03 17:04 GMT+03:00 Uros Bizjak ubiz...@gmail.com: On Mon, Aug 3, 2015 at 3:02 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: On 03/08/15 13:33, Uros Bizjak wrote: Hello! 2015-07-30 Kyrylo Tkachov kyrylo.tkac...@arm.com * ifcvt.c (noce_try_store_flag_constants): Make logic

Re: [CHKP, GCC 5] Port a set of stability chkp patches to gcc-5-branch

Ping 2015-06-19 17:10 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Hi, There was a set of stability fixes (mostly different ICEs) for Pointer Bounds Checker done in GCC 6. But only few of them were approved to be ported to GCC 5. Will it be OK to port other chkp specific stability

Re: [PATCH, PR ipa/66566] Fix ICE in early_inliner: internal compiler error: in operator[]

Ping 2015-07-13 11:47 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Ping 2015-06-18 12:54 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Hi, In early_inliner we do recompute inline summaries for edges after optimize_inline_calls, but check this summary exists in case new edges appear

[PATCH, i386, PR driver/66737] Don't pass '-z bndplt' to linker for 32bit target

-20 Ilya Enkovich enkovich@gmail.com PR target/66737 * config/i386/linux-common.h (MPX_SPEC): Use linker option for 64bit target only. diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h index 63dd8d8..da09d3d 100644 --- a/gcc/config/i386

Re: [RFC, PR target/65105] Use vector instructions for scalar 64bit computations on 32bit target

Hi, Any comments on this? Thanks, Ilya 2015-06-19 16:21 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Hi, This patch tries to improve 64bit integer computations on 32bit target. This is achieved by an additional i386 target pass which searches for all conversion candidates and tries

[PATCH, PR testsuite/66734] Support MPX tests in lto.exp

Hi, This patch initializes MPX paths in lto.exp to give check_effective_target_mpx a chance. Is it OK for trunk? Thanks, Ilya -- gcc/testsuite/ 2015-07-14 Ilya Enkovich enkovich@gmail.com PR testsuite/66734 * gcc.dg/lto/lto.exp: Initialize MPX. diff --git a/gcc

Re: [PATCH, PR ipa/66566] Fix ICE in early_inliner: internal compiler error: in operator[]

Ping 2015-06-18 12:54 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Hi, In early_inliner we do recompute inline summaries for edges after optimize_inline_calls, but check this summary exists in case new edges appear. But then it calls inline_update_overall_summary which also going

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

Ping 2015-06-01 15:26 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-05-29 1:15 GMT+03:00 Jeff Law l...@redhat.com: Right, but you're blindly propagating. The right thing to do is look at some kind of metric to estimate when it's profitable to propagate the constant back in vs leave

[PATCH, committed] Fix warning

); ^ /export/users/aguskov/MPX/git_branch/source/gcc/tree-vect-slp.c:483:8: note: 'vectype' was declared here tree vectype, scalar_type, first_op1 = NULL_TREE; ^ Thanks, Ilya -- 2015-06-24 Ilya Enkovich enkovich@gmail.com * tree-vect-slp.c

[RFC, PR target/65105] Use vector instructions for scalar 64bit computations on 32bit target

. The only test where conversion was applied is 186.crafty. I got +6% on -O2 and +10% on -Ofast + -flto. Thanks, Ilya -- 2015-06-19 Ilya Enkovich enkovich@gmail.com * config/i386/i386.c: Include dbgcnt.h. (has_non_address_hard_reg): New. (convertible_comparison_p

[CHKP, GCC 5] Port a set of stability chkp patches to gcc-5-branch

Hi, There was a set of stability fixes (mostly different ICEs) for Pointer Bounds Checker done in GCC 6. But only few of them were approved to be ported to GCC 5. Will it be OK to port other chkp specific stability fixes to GCC 5? Here is a list of patches:

[PATCH, CHKP, PR middle-end/66581] Fix internal compiler error: SSA corruption

Hi, This patch doesn't allow to reuse bounds created for abnormal ssa name to avoid coalescing issues. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for gcc-5-branch? Thanks, Ilya -- gcc/ 2015-06-19 Ilya Enkovich enkovich@gmail.com

[PATCH, PR ipa/66566] Fix ICE in early_inliner: internal compiler error: in operator[]

. This patch fixes it. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Is it OK for trunk and gcc-5-branch? Thanks, Ilya -- gcc/ 2015-06-18 Ilya Enkovich enkovich@gmail.com PR ipa/66566 * ipa-inline-analysis.c (estimate_calls_size_and_time): Check edge

[PATCH, CHKP, PR middle-end/66567] Fix internal compiler error: in assign_parms

and therefore restrict their creation. Also fix function pointers instrumentation to skip not instrumentable functions. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for gcc-5-branch? Thanks, Ilya -- gcc/ 2015-06-18 Ilya Enkovich enkovich@gmail.com

[PATCH, CHKP, PR middle-end/66568] Fix internal compiler error: in expand_expr_addr_expr_1

Hi, Currently return statement with no bounds in instrumented function causes ICE. This patch uses zero bounds in such cases instead. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for gcc-5-branch? Thanks, Ilya -- gcc/ 2015-06-18 Ilya Enkovich

[PATCH, CHKP, PR target/66569] Fix internal compiler error: in assign_by_spills

and we have no register to use. Patch delays expand of non register named bounds until vararg bounds are expanded. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for gcc-5-branch? Thanks, Ilya -- gcc/ 2015-06-18 Ilya Enkovich enkovich@gmail.com

Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX

On 04 Jun 15:53, Joseph Myers wrote: On Thu, 4 Jun 2015, Ilya Enkovich wrote: 2015-06-03 18:59 GMT+03:00 Joseph Myers jos...@codesourcery.com: You could, for example, have #if SOMETHING #define MSG %nsome msg #else #define MSG #endif and have another spec using MSG

Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX

2015-06-03 18:59 GMT+03:00 Joseph Myers jos...@codesourcery.com: You could, for example, have #if SOMETHING #define MSG %nsome msg #else #define MSG #endif and have another spec using MSG - that should work. In this case I should define SOMETHING in configure of gcc, not in configure of

Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX

2015-05-27 18:19 GMT+03:00 Jeff Law l...@redhat.com: On 05/26/2015 03:13 AM, Ilya Enkovich wrote: On 06 Apr 09:28, Jeff Law wrote: On 04/06/2015 09:17 AM, Ilya Enkovich wrote: To tell the truth, I can't figure out what this means from a user perspective. How does a user know whether

Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX

2015-06-03 18:25 GMT+03:00 Joseph Myers jos...@codesourcery.com: On Wed, 3 Jun 2015, Ilya Enkovich wrote: Spec files are not scanned by translator. I tried to split this spec into two parts to move message into a header file but with no success. Any ideas how it can be done? If a spec

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

2015-05-29 1:15 GMT+03:00 Jeff Law l...@redhat.com: Right, but you're blindly propagating. The right thing to do is look at some kind of metric to estimate when it's profitable to propagate the constant back in vs leave it hoisted out. No, the patch is not to blindly propagate but to let

Re: [i386] Scalar DImode instructions on XMM registers

2015-05-27 6:31 GMT+03:00 Jeff Law l...@redhat.com: On 05/25/2015 09:27 AM, Ilya Enkovich wrote: 2015-05-22 15:01 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-05-22 11:53 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-05-21 22:08 GMT+03:00 Vladimir Makarov vmaka...@redhat.com

Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX

On 06 Apr 09:28, Jeff Law wrote: On 04/06/2015 09:17 AM, Ilya Enkovich wrote: To tell the truth, I can't figure out what this means from a user perspective. How does a user know whether the linker option is being ignored, or if they have a new enough linker? If the linker available

Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions

Ping 2015-05-19 12:40 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Ping 2015-05-05 11:06 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Ping 2015-04-14 12:14 GMT+03:00 Ilya Enkovich enkovich@gmail.com: On 10 Apr 03:15, Jan Hubicka wrote: References are not streamed out

Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers

Ping 2015-05-19 12:39 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Ping 2015-05-05 11:05 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Ping 2015-04-14 17:35 GMT+03:00 Ilya Enkovich enkovich@gmail.com: On 10 Apr 03:27, Jan Hubicka wrote: + /* We might propagate instrumented

Re: [i386] Scalar DImode instructions on XMM registers

2015-05-22 15:01 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-05-22 11:53 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-05-21 22:08 GMT+03:00 Vladimir Makarov vmaka...@redhat.com: So, Ilya, to solve the problem you need to avoid sharing subregs for the correct LRA/reload work

Re: [i386] Scalar DImode instructions on XMM registers

2015-05-21 22:08 GMT+03:00 Vladimir Makarov vmaka...@redhat.com: On 05/21/2015 05:54 AM, Ilya Enkovich wrote: Thanks. For me it looks like an inheritance bug. It is really hard to fix the bug w/o the source code. Could you send me your patch in order I can debug RA with it to investigate

Re: [i386] Scalar DImode instructions on XMM registers

2015-05-22 11:53 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-05-21 22:08 GMT+03:00 Vladimir Makarov vmaka...@redhat.com: So, Ilya, to solve the problem you need to avoid sharing subregs for the correct LRA/reload work. Thanks a lot for your help! I'll fix it. Ilya I've fixed

[PATCH, CHKP] Fix PR middle-end/66221: lto1: error: type variant has different TYPE_ARG_TYPES

Hi, This patch fixes PR66221 by using build_distinct_type_copy instead of copy_node to copy a function type for instrumented function. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for gcc-5? Thanks, Ilya -- gcc/ 2015-05-21 Ilya Enkovich enkovich

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

Ping 2015-05-05 14:05 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-04-21 8:52 GMT+03:00 Jeff Law l...@redhat.com: On 04/17/2015 02:34 AM, Ilya Enkovich wrote: On 15 Apr 14:07, Ilya Enkovich wrote: 2015-04-14 8:22 GMT+03:00 Jeff Law l...@redhat.com: On 03/15/2015 02:30 PM, Richard

Re: [i386] Scalar DImode instructions on XMM registers

On 20 May 23:27, Vladimir Makarov wrote: On 20/05/15 04:17 AM, Ilya Enkovich wrote: On 19 May 11:22, Vladimir Makarov wrote: On 05/18/2015 08:13 AM, Ilya Enkovich wrote: 2015-05-06 17:18 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Hi Vladimir, Could you please comment

Re: [i386] Scalar DImode instructions on XMM registers

On 19 May 11:22, Vladimir Makarov wrote: On 05/18/2015 08:13 AM, Ilya Enkovich wrote: 2015-05-06 17:18 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Hi Vladimir, Could you please comment on this? Ilya, I think that the idea is worth to try but results might be mixed. It is hard

[PATCH, CHKP] Clean-up redundant gimple_build_nop calls

Hi, This patch removes redundant gimple_build_nop calls from tree-chkp.c. MPX-bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Thanks, Ilya -- 2015-05-20 Ilya Enkovich enkovich@gmail.com * tree-chkp.c (chkp_maybe_copy_and_register_bounds): Remove

Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions

Ping 2015-05-05 11:06 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Ping 2015-04-14 12:14 GMT+03:00 Ilya Enkovich enkovich@gmail.com: On 10 Apr 03:15, Jan Hubicka wrote: References are not streamed out for nodes which are referenced in a partition but don't belong to it ('continue

Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers

Ping 2015-05-05 11:05 GMT+03:00 Ilya Enkovich enkovich@gmail.com: Ping 2015-04-14 17:35 GMT+03:00 Ilya Enkovich enkovich@gmail.com: On 10 Apr 03:27, Jan Hubicka wrote: + /* We might propagate instrumented function pointer into + not instrumented function and vice versa

Re: [i386] Scalar DImode instructions on XMM registers

2015-05-06 17:18 GMT+03:00 Ilya Enkovich enkovich@gmail.com: 2015-04-25 4:32 GMT+03:00 Jan Hubicka hubi...@ucw.cz: Hi, I am adding Vladimir and Richard into CC. I tried to solve similar problem with FP math years ago by having -mfpmath=sse,i387. The idea was to allow use of i387 registers

Re: [PATCH, PR middle-end/66134] Fix coalescing for bounds used in abnormal phi

2015-05-18 12:48 GMT+03:00 Richard Biener richard.guent...@gmail.com: On Fri, May 15, 2015 at 11:43 AM, Ilya Enkovich enkovich@gmail.com wrote: Hi, This patch fixes misuse of abnormal bounds copy to avoid coalescing issue. Bootstrapped and regtested for x86_64-unknown-linux-gnu

[PATCH, PR middle-end/66134] Fix coalescing for bounds used in abnormal phi

Hi, This patch fixes misuse of abnormal bounds copy to avoid coalescing issue. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for gcc-5? Thanks, Ilya -- gcc/ 2015-05-15 Ilya Enkovich enkovich@gmail.com PR middle-end/66134 * tree

Re: [PATCH, PR target/65103, 3/3] Change rtx cost for i386 address constants

On 12 May 17:33, Uros Bizjak wrote: Hello! 2015-03-10 Ilya Enkovich ilya.enkov...@intel.com PR target/65103 * config/i386/i386.c (ix86_rtx_costs): We want to propagate link time constants into adress expressions and therefore set their cost to 0

[PATCH, CHKP] Hardcode wrapper names

, Ilya -- gcc/ 2015-05-12 Ilya Enkovich ilya.enkov...@intel.com * ipa-chkp.h (chkp_wrap_function): New. * ipa-chkp.c (chkp_wrap_function): Remove 'static'. (chkp_wrap_function_name): New. (chkp_build_instrumented_fndecl): Use chkp_wrap_function_name to get

[PATCH, i386, PR target/66048] Fix mode switching ICE for functions returning bounds

, Ilya -- gcc/ 2015-05-12 Ilya Enkovich ilya.enkov...@intel.com * function.c (diddle_return_value_1): Process bounds first. * config/i38/i386.c (ix86_function_value_regno_p): Add bnd1 register. gcc/testsuite/ 2015-05-12 Ilya Enkovich ilya.enkov...@intel.com

Re: [PATCH, PR target/65103, 3/3] Change rtx cost for i386 address constants

Ping 2015-03-10 19:14 GMT+03:00 Ilya Enkovich enkovich@gmail.com: On 10 Mar 18:11, Ilya Enkovich wrote: Hi, This patch changes rtx cost for address constants to 0 similar to what we have in address cost hook beacuse we expect them to be propagated into address expression anyway

Re: [i386] Scalar DImode instructions on XMM registers

2015-04-25 4:32 GMT+03:00 Jan Hubicka hubi...@ucw.cz: Hi, I am adding Vladimir and Richard into CC. I tried to solve similar problem with FP math years ago by having -mfpmath=sse,i387. The idea was to allow use of i387 registers when SSE ones run out and possibly also model the fact that

Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions

Ping 2015-04-14 12:14 GMT+03:00 Ilya Enkovich enkovich@gmail.com: On 10 Apr 03:15, Jan Hubicka wrote: References are not streamed out for nodes which are referenced in a partition but don't belong to it ('continue' condition in output_refs loop). Yeah, but it already special cases

Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers

Ping 2015-04-14 17:35 GMT+03:00 Ilya Enkovich enkovich@gmail.com: On 10 Apr 03:27, Jan Hubicka wrote: + /* We might propagate instrumented function pointer into + not instrumented function and vice versa. In such a + case we need to either fix function declaration

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

2015-04-21 8:52 GMT+03:00 Jeff Law l...@redhat.com: On 04/17/2015 02:34 AM, Ilya Enkovich wrote: On 15 Apr 14:07, Ilya Enkovich wrote: 2015-04-14 8:22 GMT+03:00 Jeff Law l...@redhat.com: On 03/15/2015 02:30 PM, Richard Sandiford wrote: Ilya Enkovich enkovich@gmail.com writes

Re: [PATCH] libmpx: remove AC_PROG_CXX/GCC_LIBSTDCXX_RAW_CXX_FLAGS from configure.ac

2015-04-23 12:53 GMT+03:00 Steven Noonan ste...@uplinklabs.net: This causes libmpx to fail the configure stage on my build hosts because 'xg++' was invoked with the bogus '-funconfigured-libstdc++-v3' flag, and the fallback preprocessor '/lib/cpp' did not exist on my systems. Since libmpx

Fwd: [i386] Scalar DImode instructions on XMM registers

Hi, I was looking into PR65105 and tried to generate SSE computation for a simple 64bit a + b + c sequence. Having no scalar integer instructions in SSE I have to use vector variants. Original RTL: (insn 3 2 4 2 (set (reg/v:DI 91 [ b ]) (mem/c:DI (plus:SI (reg/f:SI 16 argp)

Re: [i386] Scalar DImode instructions on XMM registers

2015-04-24 12:49 GMT+03:00 Uros Bizjak ubiz...@gmail.com: On Fri, Apr 24, 2015 at 11:45 AM, Uros Bizjak ubiz...@gmail.com wrote: On Fri, Apr 24, 2015 at 11:22 AM, Ilya Enkovich enkovich@gmail.com wrote: I was looking into PR65105 and tried to generate SSE computation for a simple 64bit

Re: [i386] Scalar DImode instructions on XMM registers

2015-04-24 12:45 GMT+03:00 Uros Bizjak ubiz...@gmail.com: On Fri, Apr 24, 2015 at 11:22 AM, Ilya Enkovich enkovich@gmail.com wrote: I was looking into PR65105 and tried to generate SSE computation for a simple 64bit a + b + c sequence. Having no scalar integer instructions in SSE I

Re: [i386] Scalar DImode instructions on XMM registers

2015-04-24 13:27 GMT+03:00 Marc Glisse marc.gli...@inria.fr: On Fri, 24 Apr 2015, Uros Bizjak wrote: Please try to generate paradoxical subreg (V2DImode subreg of V1DImode pseudo). IIRC, there is some functionality in the compiler that is able to tell if the highpart of the paradoxical

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

On 15 Apr 14:07, Ilya Enkovich wrote: 2015-04-14 8:22 GMT+03:00 Jeff Law l...@redhat.com: On 03/15/2015 02:30 PM, Richard Sandiford wrote: Ilya Enkovich enkovich@gmail.com writes: This patch allows propagation of loop invariants for i386 if propagated value is a constant

[PATCH, CHKP] Don't require IPA_REF_CHKP reference for nodes other than instrumentation thunks

. Will apply to trunk and later to gcc_5 if no objections appear. Thanks, Ilya -- gcc/ 2015-04-16 Ilya Enkovich ilya.enkov...@intel.com * cgraph.c (cgraph_node::verify_node): Require IPA_CHKP_REF for instrumentation thunks only. gcc/testsuite/ 2015-04-16 Ilya Enkovich ilya.enkov

Fwd: [PATCH, CHKP] Don't require IPA_REF_CHKP reference for nodes other than instrumentation thunks

and later to gcc_5 if no objections appear. Thanks, Ilya -- gcc/ 2015-04-16 Ilya Enkovich ilya.enkov...@intel.com * cgraph.c (cgraph_node::verify_node): Require IPA_CHKP_REF for instrumentation thunks only. gcc/testsuite/ 2015-04-16 Ilya Enkovich ilya.enkov...@intel.com

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

2015-04-14 8:22 GMT+03:00 Jeff Law l...@redhat.com: On 03/15/2015 02:30 PM, Richard Sandiford wrote: Ilya Enkovich enkovich@gmail.com writes: This patch allows propagation of loop invariants for i386 if propagated value is a constant to be used in address operand. Bootstrapped

Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions

-unknown-linux-gnu. OK for trunk? I also want to port it to GCC 5 branch after release. Thanks, Ilya -- gcc/ 2015-04-14 Ilya Enkovich ilya.enkov...@intel.com * ipa.c (symbol_table::remove_unreachable_nodes): Don't remove instumentation thunks calling reachable functions

Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers

passed. Is it OK for trunk and later for GCC 5? Thanks, Ilya -- gcc/ 2015-04-14 Ilya Enkovich ilya.enkov...@intel.com PR target/65527 * cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Add redirection for instrumented calls. * lto-wrapper.c

Re: PATCH: Add bootstrap-mpx.mk

2015-03-23 22:27 GMT+03:00 H.J. Lu hongjiu...@intel.com: Hi, This patch adds bootstrap-mpx.mk so that we test mpx in gcc build by configuring GCC with --enable-libmpx --with-build-config=bootstrap-mpx OK to install? H.J. --- 2015-03-23 H.J. Lu hongjiu...@intel.com *

[libmpx, committed] Add zero length check for memmove wrapper

Hi, This patch adds a zero length check into memmove wrapper (also affecting memcpy and mempcpy) to avoid unnecessary bounds checks. Tested on on x86_64-unknown-linux-gnu. Applied to trunk. Thanks, Ilya -- libmpx/ 2015-04-09 Ilya Enkovich ilya.enkov...@intel.com * mpxwrap

Re: [wwwdocs] Update changes.html with Intel MPX and Pointer Bounds Checker

On 09 Apr 12:32, Gerald Pfeifer wrote: On Thu, 9 Apr 2015, Ilya Enkovich wrote: This adds Pointer Bounds Checker and MPX support to GCC 5 changes. Is it OK? Nice, thank you! Can you just replace runtime checks by run-time checks and IA-32/x86-64 GNU/Linux target by x86/x86-64 GNU

[wwwdocs] Update changes.html with Intel MPX and Pointer Bounds Checker

Hi, This adds Pointer Bounds Checker and MPX support to GCC 5 changes. Is it OK? Thanks, Ilya -- --- changes.html2015-04-09 12:18:47.67230 +0300 +++ changes.html2015-04-09 12:58:23.677983000 +0300 @@ -158,20 +158,29 @@ licode-fsanitize=alignment/code: enable alignment

Re: [PATCH] Walk through thunks when propagating comdat group

/ 2015-04-08 Ilya Enkovich ilya.enkov...@intel.com * ipa-comdats.c (propagate_comdat_group): Walk through thunks. gcc/testsuite/ 2015-04-08 Ilya Enkovich ilya.enkov...@intel.com * gcc.target/i386/mpx/chkp-thunk-comdat-3.c: New. diff --git a/gcc/ipa-comdats.c b/gcc/ipa

Re: [PATCH, CHKP] Fix static const bounds creation in LTO

On 07 Apr 22:43, Jan Hubicka wrote: 2015-04-07 Ilya Enkovich ilya.enkov...@intel.com * tree-chkp.c (chkp_find_const_bounds_var): Remove. (chkp_make_static_const_bounds): Search existing symbol by assembler name. Use make_decl_one_only. gcc/testsuite/ 2015-04

Re: [PATCH, CHKP] Fix static const bounds creation in LTO

. That is why I guess you may want to just build the new var and see if already exists Honza I see. Thank you for review! Here is an updated version. Testing passed. Does it look OK? Thanks, Ilya -- gcc/ 2015-04-07 Ilya Enkovich ilya.enkov...@intel.com * tree-chkp.c

[PATCH] Walk through thunks when propagating comdat group

. Does it look OK? Thanks, Ilya -- gcc/ 2015-04-07 Ilya Enkovich ilya.enkov...@intel.com * ipa-comdats.c (propagate_comdat_group): Walk through thunks. gcc/testsuite/ 2015-04-07 Ilya Enkovich ilya.enkov...@intel.com * gcc.target/i386/mpx/chkp-thunk-comdat-3.c: New. diff

Re: [CHKP] Support returned bounds in thunks expand

-split) Honza Here is a refactored version with common code moved to tree-chkp.c. Bootstrapped and tested on x86_64-unknown-linux-gnu. Does it look OK? Thanks, Ilya -- gcc/ 2015-04-07 Ilya Enkovich ilya.enkov...@intel.com * tree-chkp.h (chkp_insert_retbnd_call): New

Re: [PATCH, CHKP] Fix ipa-comdats for instrumentation thunks

On 06 Apr 20:41, Jan Hubicka wrote: 2015-04-03 20:12 GMT+03:00 Jan Hubicka hubi...@ucw.cz: Currently ipa_comdats doesn't set comdat groups for thunks. At the I see, that is a bug. It is supposed to keep thunks in the same section as their target (thunks doesn't really work across

<    1   2   3   4   5   6   7   8   9   10   >