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, x86-64, and x32 all
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) PIC_OFFSET_TABLE_REGNUM != I
2016-02-04 19:16 GMT+03:00 Bin.Cheng :
> On Thu, Feb 4, 2016 at 3:18 PM, Ilya Enkovich wrote:
>> 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.
>
2016-02-09 17:27 GMT+03:00 Bin.Cheng :
> On Fri, Feb 5, 2016 at 10:32 AM, Ilya Enkovich wrote:
>> 2016-02-04 19:16 GMT+03:00 Bin.Cheng :
>>> On Thu, Feb 4, 2016 at 3:18 PM, Ilya Enkovich
>>> wrote:
>>>> 2016-02-04 17:12 GMT+03:00 Bin.Cheng :
>>>
2016-02-09 18:13 GMT+03:00 Bin.Cheng :
> On Tue, Feb 9, 2016 at 2:56 PM, 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 this macro was a
>>
2016-02-09 18:45 GMT+03:00 Richard Earnshaw (lists) :
> 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 this macro was a
>>
2016-02-09 19:00 GMT+03:00 Bin.Cheng :
> On Tue, Feb 9, 2016 at 3:53 PM, Ilya Enkovich wrote:
>> 2016-02-09 18:45 GMT+03:00 Richard Earnshaw (lists)
>> :
>>> On 09/02/16 14:56, Ilya Enkovich wrote:
>>>>
>>>> I agree it looks inconsistent. Bu
2016-02-09 19:24 GMT+03:00 Jeff Law :
> On 02/09/2016 07:27 AM, Bin.Cheng wrote:
>>
>> On Fri, Feb 5, 2016 at 10:32 AM, Ilya Enkovich
>> wrote:
>>>
>>> 2016-02-04 19:16 GMT+03:00 Bin.Cheng :
>>>>
>>>> On Thu, Feb 4, 2016 at 3:18 PM,
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__ ((vector_size (16)));
2016-04-05 1:59 GMT+03:00 David Guillen Fandos :
>
>
> On 04/04/16 10:55, Ilya Enkovich wrote:
>> 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
>>&
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 to false,
> falling
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 the end I
> found my
2016-04-10 3:34 GMT+03:00 David Guillen Fandos :
> On 07/04/16 09:09, Ilya Enkovich wrote:
>> 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
>&g
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 find any code differences.
>
>
2016-04-27 14:35 GMT+03:00 Kumar, Venkataramanan :
> Hi ,
>
>> -Original Message-----
>> From: Ilya Enkovich [mailto:enkovich@gmail.com]
>> Sent: Tuesday, April 26, 2016 7:09 PM
>> To: Kumar, Venkataramanan
>> Cc: vmaka...@redhat.com; gcc@gcc.gnu.or
2016-04-27 17:06 GMT+03:00 Kumar, Venkataramanan :
> Hi,
>
>> -Original Message-----
>> From: Ilya Enkovich [mailto:enkovich@gmail.com]
>> Sent: Wednesday, April 27, 2016 5:35 PM
>> To: Kumar, Venkataramanan
>> Cc: vmaka...@redhat.com; gcc@gcc.gnu.or
2014-07-07 15:47 GMT+04:00 Jakub Jelinek :
> 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 them cou
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
2014-08-25 19:08 GMT+04:00 Vladimir Makarov :
> 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
>
2014-08-26 11:49 GMT+04:00 Ilya Enkovich :
> 2014-08-25 19:08 GMT+04:00 Vladimir Makarov :
>> 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
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:
> >
> > (in
2014-08-28 0:19 GMT+04:00 Vladimir Makarov :
> 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
&g
2014-08-28 1:39 GMT+04:00 Jeff Law :
> 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_informati
2014-08-28 16:42 GMT+04:00 Uros Bizjak :
> On Thu, Aug 28, 2014 at 10:37 AM, Ilya Enkovich
> wrote:
>> 2014-08-28 1:39 GMT+04:00 Jeff Law :
>>> On 08/26/14 15:42, Ilya Enkovich wrote:
>>>>
>>>> diff --git a/gcc/calls.c b/gcc/calls.c
>>>
2014-08-28 17:01 GMT+04:00 Uros Bizjak :
> On Fri, Aug 22, 2014 at 2:21 PM, 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
2014-08-28 17:08 GMT+04:00 Uros Bizjak :
> On Thu, Aug 28, 2014 at 2:54 PM, Ilya Enkovich wrote:
>
>>>>>> diff --git a/gcc/calls.c b/gcc/calls.c
>>>>>> index 4285ec1..85dae6b 100644
>>>>>> --- a/gcc/calls.c
>>>>>> +
2014-08-28 12:28 GMT+04:00 Ilya Enkovich :
> 2014-08-28 0:19 GMT+04:00 Vladimir Makarov :
>> 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
2014-08-28 22:58 GMT+04:00 Uros Bizjak :
> On Fri, Aug 22, 2014 at 2:21 PM, Ilya Enkovich 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 register,
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
2014-09-23 20:10 GMT+04:00 Jeff Law :
> 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
2014-09-24 19:27 GMT+04:00 Jeff Law :
> On 09/24/14 00:56, Ilya Enkovich wrote:
>>
>> 2014-09-23 20:10 GMT+04:00 Jeff Law :
>>>
>>> On 09/23/14 10:03, Jakub Jelinek wrote:
>>>>
>>>>
>>>> On Tue, Sep 23, 2014 at 10:00:00AM -060
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
> 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 Checker off, but
2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
> On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
>>
>> 2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
>>>
>>> The section "Pointer Bounds Checker builtins" in extend.texi is on my
>>> list
>>&g
2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
> On 02/24/2015 01:14 AM, Ilya Enkovich wrote:
>>
>> 2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
>>>
>>> On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
>>>>
>>>>
>>>> 2015-02-20 3:4
2015-02-25 19:16 GMT+03:00 Sandra Loosemore :
> On 02/25/2015 12:56 AM, Ilya Enkovich wrote:
>>
>> 2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
>>>
>>>
>>> Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-*
>>> options ar
2015-02-26 11:30 GMT+03:00 Richard Biener :
> 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 of th
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)
2015-04-24 12:45 GMT+03:00 Uros Bizjak :
> On Fri, Apr 24, 2015 at 11:22 AM, Ilya Enkovich
> 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
2015-04-24 12:49 GMT+03:00 Uros Bizjak :
> On Fri, Apr 24, 2015 at 11:45 AM, Uros Bizjak wrote:
>> On Fri, Apr 24, 2015 at 11:22 AM, Ilya Enkovich
>> wrote:
>>
>>> I was looking into PR65105 and tried to generate SSE computation for a
>>> simple 64bi
2015-04-24 13:27 GMT+03:00 Marc Glisse :
> 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 register is zeroed.
2015-04-25 4:32 GMT+03:00 Jan Hubicka :
> 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 Pentium4 had f
2015-05-06 17:18 GMT+03:00 Ilya Enkovich :
> 2015-04-25 4:32 GMT+03:00 Jan Hubicka :
>> 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 register
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 :
> >Hi Vladimir,
> >
> >Could you please comment on this?
> >
> >
> Ilya, I think that the idea is worth to try but re
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 :
> >>>Hi Vladi
2015-05-21 22:08 GMT+03:00 Vladimir Makarov :
> 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
>>> >ord
2015-05-22 11:53 GMT+03:00 Ilya Enkovich :
> 2015-05-21 22:08 GMT+03:00 Vladimir Makarov :
>> 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.
>
&g
2015-05-22 15:01 GMT+03:00 Ilya Enkovich :
> 2015-05-22 11:53 GMT+03:00 Ilya Enkovich :
>> 2015-05-21 22:08 GMT+03:00 Vladimir Makarov :
>>> So, Ilya, to solve the problem you need to avoid sharing subregs for the
>>> correct LRA/reload work.
>>>
>>>
2015-05-27 6:31 GMT+03:00 Jeff Law :
> On 05/25/2015 09:27 AM, Ilya Enkovich wrote:
>>
>> 2015-05-22 15:01 GMT+03:00 Ilya Enkovich :
>>>
>>> 2015-05-22 11:53 GMT+03:00 Ilya Enkovich :
>>>>
>>>> 2015-05-21 22:08 GMT+03:00 Vladimir Makarov
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
-Wmissing-format
2011/7/22 Richard Guenther :
>
> Elsewhere we use an unsigned int instead of enum tree_code.
>
> Richard.
>
Thanks for the hint!
Ilya
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
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 = "-";
2013/5/17 Jakub Jelinek :
> 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 ()
>> {
>> +++ __tmp.0;+++
>>
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))
2013/7/25 Ian Lance Taylor :
> On Wed, Jul 24, 2013 at 4:36 PM, Roland McGrath 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.
>
> These are my answers and
2013/7/25 Florian Weimer :
> 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 chang
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 variant
inal 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)
2013/8/12 Terry Guo :
>
>
>> -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 suffixe
2013/8/21 Joseph S. Myers :
> 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 different paths, I am no
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 i
2013/8/27 Kalle Olavi Niemitalo :
> Ilya Enkovich 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 pointers get bounds too.
> If so, it might be good to
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 'us
2013/8/29 H.J. Lu :
> On Thu, Aug 29, 2013 at 7:33 AM, Ilya Enkovich 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 retu
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 GPR
Ping
2013/8/27 Ilya Enkovich :
> 2013/8/27 Kalle Olavi Niemitalo :
>> Ilya Enkovich writes:
>>
>>> - When we pass (return) pointer on register, we use the next
>>> available bound register to pass (return) bounds
>>
>> From the wording, it seems f
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 only
2013/10/1 Jakub Jelinek :
> 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 requi
2013/10/2 Ilya Enkovich :
> 2013/10/1 Jakub Jelinek :
>> 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.
>>>
>>>
2013/10/7 Jakub Jelinek :
> 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 &#
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 s
2012/6/29 Richard Guenther :
> On Thu, Jun 28, 2012 at 5:23 PM, Ilya Enkovich 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 as arg
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
2012/10/4 Richard Guenther :
> On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich 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 consta
2012/10/5 Richard Guenther :
> On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich wrote:
>> 2012/10/4 Richard Guenther :
>>> On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich
>>> wrote:
>>>> Hi,
>>>>
>>>> I fall into ssa verification fa
75 matches
Mail list logo
