Variable DECL_SIZE

Hi, I fall into ssa verification failure when try to pass field's DECL_SIZE as an operand for CALL_EXPR. The fail occurs if field's size is not a constant. In such case DECL_SIZE holds a VAR_DECL and I need to find it's proper SSA_NAME. I thought it may be the default one but gimple_default_def

Re: Variable DECL_SIZE

2012/10/4 Richard Guenther richard.guent...@gmail.com: On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich enkovich@gmail.com wrote: Hi, I fall into ssa verification failure when try to pass field's DECL_SIZE as an operand for CALL_EXPR. The fail occurs if field's size is not a constant

Re: Variable DECL_SIZE

2012/10/5 Richard Guenther richard.guent...@gmail.com: On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich enkovich@gmail.com wrote: 2012/10/4 Richard Guenther richard.guent...@gmail.com: On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich enkovich@gmail.com wrote: Hi, I fall into ssa

What is wrong with my SSA (ICE in SSA name coalescing)?

Hi, I'm testing GIMPLE instrumentation pass and having a trouble with SSA name coalescing. I get such error only in tests with abnormal edges. Here is a simple test I use: void foo (); void goo (char *); int test () { char *name = 0; foo(); _setjmp (0); if (!name) { name = -; }

Re: What is wrong with my SSA (ICE in SSA name coalescing)?

2013/5/17 Jakub Jelinek ja...@redhat.com: On Fri, May 17, 2013 at 04:03:25PM +0400, Ilya Enkovich wrote: Here is GIMPLE after my instrumentation. Instrumentation statements/expressions are marked with +++ test () { +++unnamed type __tmp.0;+++ char * name; int D.1761; int _5; bb

if_then_else usage in attribute computation

Hi, Recently I found a weird behavior in attribute computation when if_then_else is used. It may be easily demonstrated on i386 jump instruction. It's original length attribute definition is following: (set (attr length) (if_then_else (and (ge (minus (match_dup 0) (pc))

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

2013/7/25 Ian Lance Taylor i...@google.com: On Wed, Jul 24, 2013 at 4:36 PM, Roland McGrath rol...@hack.frob.com wrote: Will an MPX-using binary require an MPX-supporting dynamic linker to run correctly? * An old dynamic linker won't clobber %bndN directly, so that's not a problem.

Re: Intel(R) Memory Protection Extensions support in the GCC

2013/7/25 Florian Weimer fwei...@redhat.com: On 07/24/2013 05:58 PM, Zamyatin, Igor wrote: Hi All! This is to let you know that enabling of IntelŽ MPX technology (see details in http://download-software.intel.com/sites/default/files/319433-015.pdf) in GCC has been started. (Corresponding

How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)?

Hi, I'm currently trying to create multilib libraries compiled with MPX. The main difference with existing multilib variants on i386 target is that new targets (32/mpx, 64/mpx) are compatible with old variants (32, 64). Also we should not prevent user from using mpx if he does not have MPX

Re: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)?

Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Ilya Enkovich Sent: Friday, August 09, 2013 8:37 PM To: GCC Development Subject: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)? Hi, I'm currently trying to create multilib

Re: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)?

2013/8/12 Terry Guo terry@arm.com: -Original Message- From: Ilya Enkovich [mailto:enkovich@gmail.com] Sent: Monday, August 12, 2013 4:37 PM To: Terry Guo Cc: GCC Development Subject: Re: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX

Re: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)?

2013/8/21 Joseph S. Myers jos...@codesourcery.com: On Mon, 12 Aug 2013, Terry Guo wrote: them to linker. When there is only one compatible library, the linker can find it by searching all paths, the whole thing can work. But when there are more than one compatible libraries spread in

MPX ABI extension

Hi, Here is a patch to extend x86-64 psABI to support MPX [1]. A short description of changes: - There are 4 bound registers (bnd0-bnd3) added; all of them are caller-save - When we pass (return) pointer on register, we use the next available bound register to pass (return) bounds - If there

DX register is not a return value for i386?

Hi, function_value_regno_p hook implementation for i386 target (ix86_function_value_regno_p) always returns false for DX register. But DX register is used to return 128 bit values an AX:DX. Is it intentional or a bug? I'm asking because it causes problem with mode switching which fails if see

Re: DX register is not a return value for i386?

2013/8/29 H.J. Lu hjl.to...@gmail.com: On Thu, Aug 29, 2013 at 7:33 AM, Ilya Enkovich enkovich@gmail.com wrote: Hi, function_value_regno_p hook implementation for i386 target (ix86_function_value_regno_p) always returns false for DX register. But DX register is used to return 128 bit

Help with mode switching (create_pre_exit)

Hi, I'm fighting with mode switching (to be more precise with create_pre_exit function) trying to make it work for MPX. I saw create_pre_exit had some stability issues before and now I'm facing similar issues trying to have it working when bound register is returned by function in addition to

Re: MPX ABI extension

Ping 2013/8/27 Ilya Enkovich enkovich@gmail.com: 2013/8/27 Kalle Olavi Niemitalo k...@iki.fi: Ilya Enkovich enkovich@gmail.com writes: - When we pass (return) pointer on register, we use the next available bound register to pass (return) bounds From the wording, it seems function

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

Hi all, I'd like to restart discussion on this topic. I see two viable options in this thread for PLT entry for MPX. The first one is to use new relocation for calls requiring extended PLT. Linker may decide then which PLT entries should be extended and use 16 byte entries when possible. The

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

2013/10/1 Jakub Jelinek ja...@redhat.com: On Tue, Oct 01, 2013 at 04:15:53PM +0400, Ilya Enkovich wrote: I'd like to restart discussion on this topic. I see two viable options in this thread for PLT entry for MPX. The first one is to use new relocation for calls requiring extended PLT

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

2013/10/2 Ilya Enkovich enkovich@gmail.com: 2013/10/1 Jakub Jelinek ja...@redhat.com: On Tue, Oct 01, 2013 at 04:15:53PM +0400, Ilya Enkovich wrote: I'd like to restart discussion on this topic. I see two viable options in this thread for PLT entry for MPX. The first one is to use new

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

2013/10/7 Jakub Jelinek ja...@redhat.com: On Mon, Oct 07, 2013 at 01:31:29PM +0400, Ilya Enkovich wrote: Seems assembler may not always detect MPX relocation. For simple calls it may check for 'bnd' prefix, but for indirect call we need to generate MPX relocation for 'mov' instruction storing

Re: Enable EBX for x86 in 32bits PIC code

2014-07-07 15:47 GMT+04:00 Jakub Jelinek ja...@redhat.com: On Mon, Jul 07, 2014 at 03:35:06PM +0400, Evgeny Stupachenko wrote: The key problem here is that EBX is not used in register allocation. If we relax the restriction on EBX the performance is back, but there are several fails. Some of

Re: Enable EBX for x86 in 32bits PIC code

Hi, On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 32bit PIC mode. It was decided that the best approach would be to not fix ebx register, use speudo register for GOT base address and let allocator do the rest. This should be similar to how clang and icc work with

Re: Enable EBX for x86 in 32bits PIC code

2014-08-25 19:08 GMT+04:00 Vladimir Makarov vmaka...@redhat.com: On 2014-08-22 8:21 AM, Ilya Enkovich wrote: Hi, On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 32bit PIC mode. It was decided that the best approach would be to not fix ebx register, use speudo

Re: Enable EBX for x86 in 32bits PIC code

2014-08-26 11:49 GMT+04:00 Ilya Enkovich enkovich@gmail.com: 2014-08-25 19:08 GMT+04:00 Vladimir Makarov vmaka...@redhat.com: On 2014-08-22 8:21 AM, Ilya Enkovich wrote: Hi, On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 32bit PIC mode. It was decided

Re: Enable EBX for x86 in 32bits PIC code

On 26 Aug 11:25, Vladimir Makarov wrote: On 08/26/2014 04:57 AM, Ilya Enkovich wrote: I've looked into one of fails. There is still a problem with allocation in reload. Here is a piece of code which uses float constant: (insn 1199 1198 1200 96 (set (reg:SI 3 bx) (reg:SI 1301

Re: Enable EBX for x86 in 32bits PIC code

2014-08-28 0:19 GMT+04:00 Vladimir Makarov vmaka...@redhat.com: On 2014-08-26 5:42 PM, Ilya Enkovich wrote: Hi, Here is a patch I tried. I apply it over revision 214215. Unfortunately I do not have a small reproducer but the problem can be easily reproduced on SPEC2000 benchmark 175.vpr

Re: Enable EBX for x86 in 32bits PIC code

2014-08-28 1:39 GMT+04:00 Jeff Law l...@redhat.com: On 08/26/14 15:42, Ilya Enkovich wrote: diff --git a/gcc/calls.c b/gcc/calls.c index 4285ec1..85dae6b 100644 --- a/gcc/calls.c +++ b/gcc/calls.c @@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals ATTRIBUTE_UNUSED

Re: Enable EBX for x86 in 32bits PIC code

2014-08-28 16:42 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Thu, Aug 28, 2014 at 10:37 AM, Ilya Enkovich enkovich@gmail.com wrote: 2014-08-28 1:39 GMT+04:00 Jeff Law l...@redhat.com: On 08/26/14 15:42, Ilya Enkovich wrote: diff --git a/gcc/calls.c b/gcc/calls.c index 4285ec1..85dae6b

Re: Enable EBX for x86 in 32bits PIC code

2014-08-28 17:01 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Fri, Aug 22, 2014 at 2:21 PM, Ilya Enkovich enkovich@gmail.com wrote: Hi, On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 32bit PIC mode. It was decided that the best approach would be to not fix

Re: Enable EBX for x86 in 32bits PIC code

2014-08-28 17:08 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Thu, Aug 28, 2014 at 2:54 PM, Ilya Enkovich enkovich@gmail.com wrote: diff --git a/gcc/calls.c b/gcc/calls.c index 4285ec1..85dae6b 100644 --- a/gcc/calls.c +++ b/gcc/calls.c @@ -1122,6 +1122,14

Re: Enable EBX for x86 in 32bits PIC code

2014-08-28 12:28 GMT+04:00 Ilya Enkovich enkovich@gmail.com: 2014-08-28 0:19 GMT+04:00 Vladimir Makarov vmaka...@redhat.com: On 2014-08-26 5:42 PM, Ilya Enkovich wrote: Hi, Here is a patch I tried. I apply it over revision 214215. Unfortunately I do not have a small reproducer

Re: Enable EBX for x86 in 32bits PIC code

2014-08-28 22:58 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Fri, Aug 22, 2014 at 2:21 PM, Ilya Enkovich enkovich@gmail.com wrote: On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 32bit PIC mode. It was decided that the best approach would be to not fix ebx

Re: Enable EBX for x86 in 32bits PIC code

On 03 Sep 16:19, Vladimir Makarov wrote: On 2014-08-29 2:47 AM, Ilya Enkovich wrote: Seems your patch doesn't cover all cases. Attached is a modified patch (with your changes included) and a test where double constant is wrongly rematerialized. I also see in ira dump that there is still

Re: Enable EBX for x86 in 32bits PIC code

2014-09-23 20:10 GMT+04:00 Jeff Law l...@redhat.com: On 09/23/14 10:03, Jakub Jelinek wrote: On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote: On 09/23/14 08:34, Jakub Jelinek wrote: On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote: use fixed EBX at least until we

Re: Enable EBX for x86 in 32bits PIC code

2014-09-24 19:27 GMT+04:00 Jeff Law l...@redhat.com: On 09/24/14 00:56, Ilya Enkovich wrote: 2014-09-23 20:10 GMT+04:00 Jeff Law l...@redhat.com: On 09/23/14 10:03, Jakub Jelinek wrote: On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote: On 09/23/14 08:34, Jakub Jelinek wrote

define_split for specific split pass

Hello, Is there any way to specify in define_split predicate that it should work in some particular pass only? I need to create split which works in pass_split_before_sched2 only. Thanks Ilya

The problem with force_gimple_operand and TARGET_MEM_REF

Hello, I faced a problem with usage of force_gimple_operand function for specific tree. I have a TARGET_MEM_REF tree node whose address I want to pass as argument to the function call. I use build_fold_addr_expr to get address tree and then pass it to force_gimple_operand which generates strange

Re: The problem with force_gimple_operand and TARGET_MEM_REF

2012/6/29 Richard Guenther richard.guent...@gmail.com: On Thu, Jun 28, 2012 at 5:23 PM, Ilya Enkovich enkovich@gmail.com wrote: Hello, I faced a problem with usage of force_gimple_operand function for specific tree. I have a TARGET_MEM_REF tree node whose address I want to pass

tree_code enum usage in hooks.c

Hello, I need to use enum tree_code for default hook in hooks.c. I had to add tree.h include into hook.c for that. But it caused some errors in gcc build: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes

Re: tree_code enum usage in hooks.c

2011/7/22 Richard Guenther richard.guent...@gmail.com: Elsewhere we use an unsigned int instead of enum tree_code. Richard. Thanks for the hint! Ilya

Re: need help with Pointer Bounds Checking documentation

2015-02-20 3:48 GMT+03:00 Sandra Loosemore san...@codesourcery.com: The section Pointer Bounds Checker builtins in extend.texi is on my list for being in need of copy-editing, but reading through the existing text, I am quite confused. In several places it refers to turning the Pointer Bounds

Re: need help with Pointer Bounds Checking documentation

2015-02-25 19:16 GMT+03:00 Sandra Loosemore san...@codesourcery.com: On 02/25/2015 12:56 AM, Ilya Enkovich wrote: 2015-02-24 19:47 GMT+03:00 Sandra Loosemore san...@codesourcery.com: Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-* options are listed in c-family

Re: need help with Pointer Bounds Checking documentation

2015-02-20 19:39 GMT+03:00 Sandra Loosemore san...@codesourcery.com: On 02/20/2015 01:12 AM, Ilya Enkovich wrote: 2015-02-20 3:48 GMT+03:00 Sandra Loosemore san...@codesourcery.com: The section Pointer Bounds Checker builtins in extend.texi is on my list for being in need of copy-editing

Re: MPX runtime inclusion for GCC 5

2015-02-26 11:30 GMT+03:00 Richard Biener rguent...@suse.de: On Wed, 25 Feb 2015, Jeff Law wrote: So the steering committee has agreed to include the MPX runtime in GCC. The runtime bits are a necessary component to actually make use of the MPX capabilities. GCC is a downstream consumer

Re: need help with Pointer Bounds Checking documentation

2015-02-24 19:47 GMT+03:00 Sandra Loosemore san...@codesourcery.com: On 02/24/2015 01:14 AM, Ilya Enkovich wrote: 2015-02-20 19:39 GMT+03:00 Sandra Loosemore san...@codesourcery.com: On 02/20/2015 01:12 AM, Ilya Enkovich wrote: 2015-02-20 3:48 GMT+03:00 Sandra Loosemore san

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: [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: [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: [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

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: [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 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

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

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

Re: x32 libraries

For libmpx the reason is that MPX ISA doesn't support x32. I.e. MPX instructions can't use 32bit bounds in 64bit mode. Ilya 2015-11-18 9:34 GMT+03:00 Ulrich Drepper : > Is there a reason why libmpx and libgccjit aren't build for x32? This > is in the case when building IA-32,

Re: Inconsistent initialization for pic_offset_table_rtx?

2016-02-09 18:45 GMT+03:00 Richard Earnshaw (lists) <richard.earns...@arm.com>: > On 09/02/16 14:56, Ilya Enkovich wrote: >> >> I agree it looks inconsistent. But I don't think PIC_OFFSET_TABLE_REGNUM is >> supposed to return pseudo regno. Using EBX_REG value for thi

Re: Inconsistent initialization for pic_offset_table_rtx?

2016-02-09 19:00 GMT+03:00 Bin.Cheng <amker.ch...@gmail.com>: > On Tue, Feb 9, 2016 at 3:53 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> 2016-02-09 18:45 GMT+03:00 Richard Earnshaw (lists) >> <richard.earns...@arm.com>: >>> On 09/02/16 14:

Re: Inconsistent initialization for pic_offset_table_rtx?

2016-02-09 18:13 GMT+03:00 Bin.Cheng <amker.ch...@gmail.com>: > On Tue, Feb 9, 2016 at 2:56 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> >> I agree it looks inconsistent. But I don't think PIC_OFFSET_TABLE_REGNUM is >> supposed to return pseudo regno. U

Re: Inconsistent initialization for pic_offset_table_rtx?

2016-02-04 17:12 GMT+03:00 Bin.Cheng : > Hi, > I noticed that pic_offset_table_rtx is initialized twice in GCC. Take > x86_32 as an example. > The first initialization is done in emit_init_regs, with below code: > > pic_offset_table_rtx = NULL_RTX; > if ((unsigned)

Re: Inconsistent initialization for pic_offset_table_rtx?

2016-02-04 19:16 GMT+03:00 Bin.Cheng <amker.ch...@gmail.com>: > On Thu, Feb 4, 2016 at 3:18 PM, Ilya Enkovich <enkovich@gmail.com> wrote: >> 2016-02-04 17:12 GMT+03:00 Bin.Cheng <amker.ch...@gmail.com>: >>> Hi, >>> I noticed that pic_offset

Re: Vector registers on MIPS arch

2016-04-06 1:50 GMT+03:00 David Guillen Fandos : > > Thanks again Ilya, > > That seems to help to solve the problem. Now I'm facing another issue. > It seems the tree-vec-generic pass is promoting my vector operations to > BLKmode and therefore the VECTOR_MODE_P macro evaluates

Re: Vector registers on MIPS arch

2016-04-07 0:49 GMT+03:00 David Guillen Fandos : > > Thanks a lot Ilya! > > I managed to get it working. There were some bugs regarding register > allocation that ended up promoting the class to be BLKmode instead of > V4SFmode. I had to debug it a bit, which is tricky, but in

Re: Vector registers on MIPS arch

2016-04-10 3:34 GMT+03:00 David Guillen Fandos <da...@davidgf.net>: > On 07/04/16 09:09, Ilya Enkovich wrote: >> 2016-04-07 0:49 GMT+03:00 David Guillen Fandos <da...@davidgf.net>: >>> >>> Thanks a lot Ilya! >>> >>> I managed t

Re: Vector registers on MIPS arch

2016-04-02 3:32 GMT+03:00 David Guillen Fandos : > Hello there! > > I'm trying to add some vector registers to a MIPS arch (32 bit). This > arch has 32 x 128 bit registers that can essentially be seen as V4SF. > So far I'm using this test: > > volatile float foo __attribute__

Re: Vector registers on MIPS arch

2016-04-05 1:59 GMT+03:00 David Guillen Fandos <da...@davidgf.net>: > > > On 04/04/16 10:55, Ilya Enkovich wrote: >> 2016-04-02 3:32 GMT+03:00 David Guillen Fandos <da...@davidgf.net>: >>> Hello there! >>> >>> I'm trying to add some vector reg

Re: Question on TARGET_MMX and X86_TUNE_GENERAL_REGS_SSE_SPILL

2016-04-14 8:39 GMT+03:00 Kumar, Venkataramanan : > Hi, > > X86_TUNE_GENERAL_REGS_SSE_SPILL: Try to spill general regs to SSE regs > instead of memory. > > I tried enabling the above tuning with -march=bdver4 -Ofast > -mtune-ctrl=general_regs_sse_spill. > I did not

Re: Question on TARGET_MMX and X86_TUNE_GENERAL_REGS_SSE_SPILL

2016-04-27 14:35 GMT+03:00 Kumar, Venkataramanan <venkataramanan.ku...@amd.com>: > Hi , > >> -Original Message----- >> From: Ilya Enkovich [mailto:enkovich@gmail.com] >> Sent: Tuesday, April 26, 2016 7:09 PM >> To: Kumar, Venkataramanan <ven

Re: Question on TARGET_MMX and X86_TUNE_GENERAL_REGS_SSE_SPILL

2016-04-27 17:06 GMT+03:00 Kumar, Venkataramanan <venkataramanan.ku...@amd.com>: > Hi, > >> -Original Message----- >> From: Ilya Enkovich [mailto:enkovich@gmail.com] >> Sent: Wednesday, April 27, 2016 5:35 PM >> To: Kumar, Venkataramanan <ven

Re: [PATCH, Pointer Bounds Checker 3/x] Target hooks for Pointer Bounds Checker

Ping 2014-05-06 16:11 GMT+04:00 Ilya Enkovich enkovich@gmail.com: PING 2014-04-16 15:52 GMT+04:00 Ilya Enkovich enkovich@gmail.com: Hi, This patch introduces target hooks to be used by Pointer Bounds Checker. Hooks set is different from what was approved for 4.9 (and later

Re: [PATCH, Pointer Bounds Checker 4/x] Built-in functions

Ping 2014-05-06 16:11 GMT+04:00 Ilya Enkovich enkovich@gmail.com: PING 2014-04-16 16:19 GMT+04:00 Ilya Enkovich enkovich@gmail.com: Hi, This patch introduces built-in functions used by Pointer Bounds Checker. It is mostly similar to what was reverted from 4.9, I just added types

Re: [PATCH, Pointer Bounds Checker 9/x] Cgraph extension

Ping 2014-05-06 16:13 GMT+04:00 Ilya Enkovich enkovich@gmail.com: Ping 2014-04-16 18:03 GMT+04:00 Ilya Enkovich enkovich@gmail.com: Hi, This patch introduces changes in call graph for Pointer Bounds Checker. New fields instrumented_version, instrumentation_clone and orig_decl

[PATCH, i386] Add prefixes avoidance tuning for silvermont target

% Bootstrapped and tested on linux-x86_64. Does it look OK for trunk? Thanks, Ilya -- gcc/ 2014-07-02 Ilya Enkovich ilya.enkov...@intel.com * config/i386/constraints.md (Yr): New. * config/i386/i386.h (reg_class): Add NO_REX_SSE_REGS. (REG_CLASS_NAMES): Likewise

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

). 2014-07-02 Ilya Enkovich ilya.enkov...@intel.com * config/i386/constraints.md (Yr): New. * config/i386/i386.h (reg_class): Add NO_REX_SSE_REGS. (REG_CLASS_NAMES): Likewise. (REG_CLASS_CONTENTS): Likewise. * config/i386/sse.md (*vec_concatv2sf_sse4_1): Add alternatives which use only

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-02 20:21 GMT+04:00 Andi Kleen a...@firstfloor.org: Ilya Enkovich enkovich@gmail.com writes: Silvermont processors have penalty for instructions having 4+ bytes of prefixes (including escape bytes in opcode). This situation happens when REX prefix is used in SSE4 instructions

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-02 20:27 GMT+04:00 Jakub Jelinek ja...@redhat.com: On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote: Ilya Enkovich enkovich@gmail.com writes: Silvermont processors have penalty for instructions having 4+ bytes of prefixes (including escape bytes in opcode

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-03 14:56 GMT+04:00 Jakub Jelinek ja...@redhat.com: On Thu, Jul 03, 2014 at 02:49:10PM +0400, Ilya Enkovich wrote: 2014-07-02 20:21 GMT+04:00 Andi Kleen a...@firstfloor.org: Ilya Enkovich enkovich@gmail.com writes: Silvermont processors have penalty for instructions having 4

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-03 15:11 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Thu, Jul 3, 2014 at 12:45 PM, Ilya Enkovich enkovich@gmail.com wrote: Silvermont processors have penalty for instructions having 4+ bytes of prefixes (including escape bytes in opcode). This situation happens when REX prefix

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-03 16:07 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich enkovich@gmail.com wrote: I didn't find a nice way to fix peephole2 patterns to take register constraints into account. Is there any way to do it? Use REX_SSE_REGNO_P (REGNO (operands

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

Ping 2014-07-03 17:38 GMT+04:00 Ilya Enkovich enkovich@gmail.com: 2014-07-03 16:07 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich enkovich@gmail.com wrote: I didn't find a nice way to fix peephole2 patterns to take register constraints

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-14 23:58 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Thu, Jul 3, 2014 at 3:38 PM, Ilya Enkovich enkovich@gmail.com wrote: 2014-07-03 16:07 GMT+04:00 Uros Bizjak ubiz...@gmail.com: On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich enkovich@gmail.com wrote: I didn't find a nice

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

On 15 Jul 10:42, Uros Bizjak wrote: On Tue, Jul 15, 2014 at 10:25 AM, Ilya Enkovich enkovich@gmail.com wrote: Also fully restrict xmm8-15 does not seem right. It is just costly but not fully disallowed. As said earlier, you can try Ya*x as a constraint. I tried it. It does

Re: [PATCH, Pointer Bounds Checker 9/x] Cgraph extension

On 22 Jul 21:56, Jeff Law wrote: On 04/16/14 08:03, Ilya Enkovich wrote: Hi, This patch introduces changes in call graph for Pointer Bounds Checker. New fields instrumented_version, instrumentation_clone and orig_decl are added for cgraph_node: - instrumentation_clone field is 1

Re: [PATCH, Pointer Bounds Checker 9/x] Cgraph extension

2014-07-24 15:38 GMT+04:00 Jan Hubicka hubi...@ucw.cz: Hello, diff --git a/gcc/cgraph.h b/gcc/cgraph.h index a6a51cf..5e702a7 100644 --- a/gcc/cgraph.h +++ b/gcc/cgraph.h @@ -191,6 +191,7 @@ struct GTY(()) cgraph_thunk_info { tree alias; bool this_adjusting; bool

Re: [PATCH, Pointer Bounds Checker 9/x] Cgraph extension

2014-07-24 17:41 GMT+04:00 Jan Hubicka hubi...@ucw.cz: So the patch is introducing yet another notion of clone (in addition to existing virtual clones and function versions used by ifun) and you add a new type of reference (CHKP) to link the original and the clone. Why do you need

[PATCH, MPX runtime 1/2] Integrate MPX runtime library

-- 2014-11-11 Ilya Enkovich ilya.enkov...@intel.com * Makefile.def: Add libmpx. * configure.ac: Add libmpx. * Makefile.in: Regenerate. * configure: Regenerate. gcc/ 2014-11-11 Ilya Enkovich ilya.enkov...@intel.com * gcc.c (MPX_SPEC): New

Re: [PATCH, MPX runtime 2/2] Add MPX tests

2014-11-11 22:55 GMT+03:00 Jeff Law l...@redhat.com: On 11/11/14 11:42, Mike Stump wrote: On Nov 11, 2014, at 8:02 AM, Ilya Enkovich enkovich@gmail.com wrote: This patch adds simple runtime MPX tests. Make check shows no fails for mpx.exp suite for x86_64-unknown-linux-gnu{-m32,-mx32

Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library

2014-11-11 23:02 GMT+03:00 Jeff Law l...@redhat.com: On 11/11/14 08:34, Ilya Enkovich wrote: Hi, This patch integrates MPX runtime library into GCC source tree. MPX runtime is responsible for initialization of MPX feature in HW, signal handling, reporting etc. Library is linked to codes

Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library

2014-11-11 21:09 GMT+03:00 Joseph Myers jos...@codesourcery.com: On Tue, 11 Nov 2014, Joseph Myers wrote: You have lots of static writable variables. Are you sure all those variables are handled in a thread-safe way (e.g. only modified before any threads start)? Another general

Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library

On 11 Nov 20:25, Joseph Myers wrote: On Tue, 11 Nov 2014, Andi Kleen wrote: Joseph Myers jos...@codesourcery.com writes: On Tue, 11 Nov 2014, Ilya Enkovich wrote: Hi, This patch integrates MPX runtime library into GCC source tree. MPX runtime is responsible

Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library

2014-11-13 0:40 GMT+03:00 Joseph Myers jos...@codesourcery.com: On Wed, 12 Nov 2014, Ilya Enkovich wrote: MPX runtime needs to be linked with programs using MPX because it initializes hardware. Without it all MPX instructions are just NOPs. Thus it's not an extra functionality

Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library

2014-11-13 2:03 GMT+03:00 Joseph Myers jos...@codesourcery.com: On Thu, 13 Nov 2014, Ilya Enkovich wrote: It's hard to decide which of runtime functionality should be considered as basic and how it should be used. We may say that the only basic thing is hardware enabling which is enable_mpx

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 2/5] Instrument builtin calls

2014-11-14 9:49 GMT+03:00 Jeff Law l...@redhat.com: On 11/06/14 05:10, Ilya Enkovich wrote: Hi, This patch enables instrumentation of chosen builtin calls. Thanks, Ilya -- 2014-11-06 Ilya Enkovich ilya.enkov...@intel.com * ipa-chkp.c (chkp_versioning): Clone builtin functions

Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 1/5] Builtin codes and decls

2014-11-14 9:43 GMT+03:00 Jeff Law l...@redhat.com: On 11/06/14 04:48, Ilya Enkovich wrote: -- 2014-11-06 Ilya Enkovich ilya.enkov...@intel.com * tree-core.h (built_in_class): Add builtin codes to be used by Pointer Bounds Checker for instrumented builtin functions

[PATCH, MPX wrappers 1/3] Add MPX wrappers library

Enkovich ilya.enkov...@intel.com * gcc.c (MPX_SPEC): Add wrappers library. libmpx/ 2014-11-14 Ilya Enkovich ilya.enkov...@intel.com * Makefile.am (SUBDIRS): New. (MAKEOVERRIDES): New. * Makefile.in: Regenerate. * configure.ac: Add mpxintr/Makefile

[PATCH, MPX wrappers 2/3] Replace some function calls with wrapper calls during instrumentation

Hi, This patch adds wrapper calls. It's simply achieved by using proper name for builtin clones. Patches apply over builtins instrumentation series. Thanks, Ilya -- 2014-11-14 Ilya Enkovich ilya.enkov...@intel.com * c-family/c.opt (fchkp-use-wrappers): New. * ipa-chkp.c

[PATCH, MPX wrappers 3/3] Tests

Hi, Here are few tests for MPX wrappers. Will add more in case patches #1,2 are OK. Thanks, Ilya -- 2014-11-14 Ilya Enkovich ilya.enkov...@intel.com * lib/mpx-dg.exp (mpx_link_flags): Set path to wrappers library. * gcc.target/i386/mpx/calloc-1-lbv.c: New

  1   2   3   4   5   6   7   8   9   10   >