Possible issue with using LAST_INSN_CODE

[Claudiu Zissulescu]

Hi,

The LAST_INSN_CODE is used to mark the last instruction code valid for a 
particular architecture (e.g., For ARM the value of LAST_INSN_CODE is 3799). 
Also this code (i.e., 3799) is used by a predicated instruction (e.g., for ARM 
this code is used by predicated version of arm_usatsihi => {*p arm_usatsihi}). 

However, the LAST_INSN_CODE macro is used by lra, recog and tree-vect-stmts to 
dimension various arrays which may lead to various errors. 

For example, when calling preprocess_insn_constraints (recog.c:2444), the 
compilation may go berserk when evaluating  "if 
(this_target_recog->x_op_alt[icode])" line when icode is  exactly the 
LAST_INSN_CODE as  "this_target_recog->x_op_alt" is dimensioned up to 
LAST_INSN_CODE (recog.h:397).

A possible solution is having the LAST_INSN_CODE value to be exactly the value 
returned by get_num_isns_codes() (gencodes.c:89). Alternatively is to use 
LAST_INSN_CODE+1 when defining an array.

Please can someone confirm my observation. And what will be the best solution 
for this.

Thanks,
Claudiu

Re: Possible issue with using LAST_INSN_CODE

[Claudiu Zissulescu]

Hi Jeff,

In the gencodes.c:89, it explicitly  decrements by one the return
value of get_num_insn_codes(). While for the get_num_insn_codes is
stated this:

/* Return the number of possible INSN_CODEs.  Only meaningful once the
   whole file has been processed.  */

I can provide an example for the ARC port where it crashes due to
LAST_INSN_CODE issue. Probably it can be reproduced with other more
popular port like ARM.

//Claudiu


On Thu, Aug 20, 2015 at 6:54 PM, Jeff Law  wrote:
> On 08/20/2015 02:54 AM, Claudiu Zissulescu wrote:
>>
>> Hi,
>>
>> The LAST_INSN_CODE is used to mark the last instruction code valid
>> for a particular architecture (e.g., For ARM the value of
>> LAST_INSN_CODE is 3799). Also this code (i.e., 3799) is used by a
>> predicated instruction (e.g., for ARM this code is used by predicated
>> version of arm_usatsihi => {*p arm_usatsihi}).
>>
>> However, the LAST_INSN_CODE macro is used by lra, recog and
>> tree-vect-stmts to dimension various arrays which may lead to various
>> errors.
>>
>> For example, when calling preprocess_insn_constraints (recog.c:2444),
>> the compilation may go berserk when evaluating  "if
>> (this_target_recog->x_op_alt[icode])" line when icode is  exactly the
>> LAST_INSN_CODE as  "this_target_recog->x_op_alt" is dimensioned up to
>> LAST_INSN_CODE (recog.h:397).
>>
>> A possible solution is having the LAST_INSN_CODE value to be exactly
>> the value returned by get_num_isns_codes() (gencodes.c:89).
>> Alternatively is to use LAST_INSN_CODE+1 when defining an array.
>>
>> Please can someone confirm my observation. And what will be the best
>> solution for this.
>
> It seems to me like something has been broken then.
>
> LAST_INSN_CODE is supposed to be higher than any insn defined by the
> backend.
>
>
> Jeff

Write after approval question

[Claudiu Zissulescu]

Hello,

I am working on ARC GCC backend and I have a number of successful 
contributions. To easy up my interaction with the ARC maintainer, I would like 
to apply for the write after approval right. However, it is unclear for me who 
will be the person who approves my access as I need to indicate this person in 
the application form.  Is this person the ARC maintainer Joern Rennecke? Are my 
contributions enough?

My patches:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00657.html
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01199.html

Thank you,
Claudiu

RE: Write after approval question

[Claudiu Zissulescu]

Thank you Jeff for the clarifications

Best,
Claudiu

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 28, 2015 6:30 PM
> To: Claudiu Zissulescu; gcc@gcc.gnu.org
> Cc: Francois Bedard; jeremy.benn...@embecosm.com; g...@amylaar.uk
> Subject: Re: Write after approval question
> 
> On 10/28/2015 08:30 AM, Claudiu Zissulescu wrote:
> > Hello,
> >
> > I am working on ARC GCC backend and I have a number of successful
> contributions. To easy up my interaction with the ARC maintainer, I would
> like to apply for the write after approval right. However, it is unclear for 
> me
> who will be the person who approves my access as I need to indicate this
> person in the application form.  Is this person the ARC maintainer Joern
> Rennecke? Are my contributions enough?
> >
> > My patches:
> > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00657.html
> > https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01199.html
> Joern would be the best sponsor since he's had the most interactions with
> you.
> 
> jeff

Possible bug: Unaligned bit-field address when predictive commoning.

[Claudiu Zissulescu]

Hi,

I've been trying the following simple test case on latest gcc, and it seems to 
produce unwanted unaligned accesses for bit-fields.

Test cases:

struct lock_chain {
  unsigned int irq_context: 2,
depth: 6,
base: 24;
};

struct lock_chain * foo (struct lock_chain *chain)
{
  int i;
  for (i = 0; i < 100; i++)
{
  chain[i+1].base = chain[i].base;
}
  return chain;
}

GCC options -O3 (we need predictive commoning to kick in).

The result for ARM:

.cpu arm926ej-s
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "t01.c"
.text
.align  2
.global foo
.syntax unified
.arm
.fpu softvfp
.type   foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r1, [r0, #1] Unaligned access
add r3, r0, #4
lsl r1, r1, #8
add ip, r0, #404
.L2:
ldrbr2, [r3]@ zero_extendqisi2
orr r2, r1, r2
str r2, [r3], #4
cmp r3, ip
bne .L2
bx  lr
.size   foo, .-foo
.ident  "GCC: (GNU) 7.0.0 20160502 (experimental)"

Please observe the ldr instruction will access an unaligned address.

I observed this issue for ARC processor, but because the ARM is more popular, 
I've use it for this case.

Is this expected behavior or do I miss something?

Thank you,
Claudiu

Re: Possible bug: Unaligned bit-field address when predictive commoning.

[Claudiu Zissulescu]

On 12/05/16 12:37, Richard Biener wrote:

On Thu, May 12, 2016 at 12:17 PM, Richard Biener
 wrote:

On Thu, May 12, 2016 at 12:10 PM, Claudiu Zissulescu
 wrote:

Hi,

I've been trying the following simple test case on latest gcc, and it seems to 
produce unwanted unaligned accesses for bit-fields.

Test cases:

struct lock_chain {
   unsigned int irq_context: 2,
 depth: 6,
 base: 24;
};

struct lock_chain * foo (struct lock_chain *chain)
{
   int i;
   for (i = 0; i < 100; i++)
 {
   chain[i+1].base = chain[i].base;
 }
   return chain;
}

GCC options -O3 (we need predictive commoning to kick in).

The result for ARM:

 .cpu arm926ej-s
 .eabi_attribute 20, 1
 .eabi_attribute 21, 1
 .eabi_attribute 23, 3
 .eabi_attribute 24, 1
 .eabi_attribute 25, 1
 .eabi_attribute 26, 1
 .eabi_attribute 30, 2
 .eabi_attribute 34, 0
 .eabi_attribute 18, 4
 .file   "t01.c"
 .text
 .align  2
 .global foo
 .syntax unified
 .arm
 .fpu softvfp
 .type   foo, %function
foo:
 @ args = 0, pretend = 0, frame = 0
 @ frame_needed = 0, uses_anonymous_args = 0
 @ link register save eliminated.
 ldr r1, [r0, #1]<<<<<<<<<<<< Unaligned access
 add r3, r0, #4
 lsl r1, r1, #8
 add ip, r0, #404
.L2:
 ldrbr2, [r3]@ zero_extendqisi2
 orr r2, r1, r2
 str r2, [r3], #4
 cmp r3, ip
 bne .L2
 bx  lr
 .size   foo, .-foo
 .ident  "GCC: (GNU) 7.0.0 20160502 (experimental)"

Please observe the ldr instruction will access an unaligned address.

I observed this issue for ARC processor, but because the ARM is more popular, 
I've use it for this case.

Is this expected behavior or do I miss something?


Looks like a bug - please file a bugreport.


Try

Index: gcc/tree-predcom.c
===
--- gcc/tree-predcom.c  (revision 236159)
+++ gcc/tree-predcom.c  (working copy)
@@ -1391,9 +1395,10 @@ ref_at_iteration (data_reference_p dr, i
&& DECL_BIT_FIELD (TREE_OPERAND (DR_REF (dr), 1)))
  {
tree field = TREE_OPERAND (DR_REF (dr), 1);
+  tree type = build_aligned_type (DECL_BIT_FIELD_TYPE (field),
+ BITS_PER_UNIT);
return build3 (BIT_FIELD_REF, TREE_TYPE (DR_REF (dr)),
-build2 (MEM_REF, DECL_BIT_FIELD_TYPE (field),
-addr, alias_ptr),
+build2 (MEM_REF, type, addr, alias_ptr),
  DECL_SIZE (field), bitsize_zero_node);
  }
else


Richard.


Richard.


Thank you,
Claudiu


It looks better. For ARC I need to optimize this type of access as it 
uses three loads, and it can do with two. Anyhow the bug id is: 71083


Thank you,
Claudiu

ARC's pending patches

[Claudiu Zissulescu]

Hi,

Until GCC steering committee will take a decision about ARC's maintainer, 
please can any of the global reviewer review my pending ARC's patches:

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01100.html
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01101.html
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02327.html
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01290.html
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02041.html
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02042.html
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02044.html
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00386.html
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00389.html

Any help is highly appreciated,
Claudiu

RE: ARC's pending patches

[Claudiu Zissulescu]

Hi,

On the last GNU Cauldron, Joern notify us he want to stand off as an ARC 
maintainer, not giving a particular date though. He did review a number of 
patches in the beginning of this year, and after that he went silent. I tried 
to contact him directly on the subject, without success. Hence, I wrote an 
email to Richard Earnshaw expressing my concerns about ARC backend, as his name 
is in top of the global reviewers. He declined competency on the topic, and 
forwarded my email to GNU steering committee to solve the issue.

Please let me know if you need more info,
Claudiu


> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Monday, September 05, 2016 4:13 PM
> To: Claudiu Zissulescu ; Joern Rennecke
> 
> Cc: Francois Bedard ; gcc@gcc.gnu.org
> Subject: Re: ARC's pending patches
> 
> Hi Claudiu,
> 
> On Mon, 5 Sep 2016, Claudiu Zissulescu wrote:
> > Until GCC steering committee will take a decision about ARC's
> > maintainer
> 
> can you please share some more background on this?  I do not
> recall any conversation around this at the steering committee.
> 
> 
> The GCC MAINTAINERS file still lists
> 
>   arc portJoern Rennecke  
> 
> and I am copying Jörn on this.  In my experience, the best
> way to get additional maintainers or have a replacement is
> for the (or a) current maintainer to nominate her.
> 
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01100.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01101.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02327.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01290.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02041.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02042.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02044.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00386.html
> > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00389.html
> 
> Gerald

RE: Andrew Burgess and Claudiu Zissulescu as reviewers for the ARC port

[Claudiu Zissulescu]

Big thanks to the GCC steering committee for quick resolution found for the ARC 
port. 

Thank you for all the trust,
Claudiu

> -Original Message-
> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
> Sent: Monday, September 26, 2016 2:19 PM
> To: gcc@gcc.gnu.org; Claudiu Zissulescu
> ; andrew.burg...@embecosm.com
> Subject: Andrew Burgess and Claudiu Zissulescu as reviewers for the ARC
> port
> 
> I am pleased to announce that the GCC Steering Committee has
> appointed Andrew Burgess and Claudiu Zissulescu as reviewers for
> the ARC port.
> 
> Please join me in congratulating Andrew and Claudiu on their new roles.
> 
> Claudiu / Andrew - please update your listing in the MAINTAINERS file.
> 
> Thanks,
> Ramana

VREGS cannot handle subreg(mem (plus ...)) pattern

[Claudiu Zissulescu]

Hi,

Out of the expand  I get the following pattern:

(set (reg:SI 203)
(subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-vars)
(const_int -320 [0xfec0])) [4 buf1.state+0 S8 
A32]) 4))

which it looks too complex to be handled by the VREGS pass. I.e., in the 
instantiate_virtual_regs_in_insn() function, it seems we handle only subreg 
(reg ...).
As a consequence, the virtual-stack-vars reg is not instantiated leading to a 
compiler internal error later on.

Now, is the above pattern expected out of expand? Is the VREGS expected to 
handle this type of pattern?

Many thanks,
Claudiu

Re: VREGS cannot handle subreg(mem (plus ...)) pattern

[Claudiu Zissulescu]

Sorry for the noise, I've remember I had a similar issue in the past.

Thanks,
Claudiu

On Tue, Oct 11, 2016 at 4:48 PM, Claudiu Zissulescu
 wrote:
> Hi,
>
> Out of the expand  I get the following pattern:
>
> (set (reg:SI 203)
> (subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-vars)
> (const_int -320 [0xfec0])) [4 buf1.state+0 S8 
> A32]) 4))
>
> which it looks too complex to be handled by the VREGS pass. I.e., in the 
> instantiate_virtual_regs_in_insn() function, it seems we handle only subreg 
> (reg ...).
> As a consequence, the virtual-stack-vars reg is not instantiated leading to a 
> compiler internal error later on.
>
> Now, is the above pattern expected out of expand? Is the VREGS expected to 
> handle this type of pattern?
>
> Many thanks,
> Claudiu

RE: VREGS cannot handle subreg(mem (plus ...)) pattern

[Claudiu Zissulescu]

Hi Jeff,

> IIRC you're not supposed to have (subreg (mem)) expressions at this point.
> 
> Any (subreg (mem)) at this point can be trivially turned into a simple
> memory load.
> 
The issue is that the mode_dependent_address_p hook returns true, thus the 
simplify_subreg() will not simplify the subref(mem) as expected (see 
simplify-rtx.c:6045). Everything boils down in having the subreg(mem) while 
expanding (via simplify_gen_subreg -> emit_store_flag_1).

So, a solution (also which I applied a while back) is to relax ARC's 
mode_dependent_address_p  hook avoiding in this way the above issue. Not very 
sure about it though.

Thanks,
Claudiu

Question about ASMCONS

[Claudiu Zissulescu]

Hi guys,

I have the following rtl before asmcons pass:

(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2]  )
] ARC_UNSPEC_GOTOFFPC))
]
 [
(asm_input:SI ("0") ../t02.c:9)
]
 [] ../t02.c:9)) ../t02.c:9 -1
 (nil))

Asmcons pass leads to this:

(insn 13 3 8 2 (set (reg:SI 157 [ list ])
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2]  )
] ARC_UNSPEC_GOTOFFPC))) ../t02.c:9 -1
 (nil))
(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2]  )
] ARC_UNSPEC_GOTOFFPC))
]
 [
(asm_input:SI ("0") ../t02.c:9)
]
 [] ../t02.c:9)) ../t02.c:9 -1
 (nil))

Is the above output correct? My understanding is that the insn 8 needs be 
changed to have as input the reg:SI 157.

Thanks,
Claudiu

Re: Question about ASMCONS

[Claudiu Zissulescu]

On 19/12/2016 18:06, Segher Boessenkool wrote:

Hi Claudiu,

On Mon, Dec 19, 2016 at 12:28:54PM +, Claudiu Zissulescu wrote:

I have the following rtl before asmcons pass:

(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2]  )
] ARC_UNSPEC_GOTOFFPC))
]
 [
(asm_input:SI ("0") ../t02.c:9)
]
 [] ../t02.c:9)) ../t02.c:9 -1
 (nil))


[ snip ]

asmcons eventual does reg_overlap_mentioned_p on the input of the move
it created with an input of the asm.  The very first thing
reg_overlap_mentioned_p tests for is if the thing is constant.  And it
is here, and that makes no sense at all (since it is an output, too!)

So how did that happen?

Right, the reg_overlap_mentioned_p returns zero letting the insn 8 
unchanged.
The problem is observed in crtstuff.c when compiling __do_globa_dtor_aux 
(line 398). Here it is a short test code:


typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1] = { (func_ptr)(-1) };

void foo (int a)
{
  func_ptr *dtor_list;
  __asm ("" : "=g" (dtor_list) : "0" (__DTOR_LIST__));
  dtor_list[a]();
}

compiled with -O1 -fpic -mcpu=archs for ARC ;) it will crash somewhere 
in verify_rtx_sharing due to the duplicated const(unspec) thingy.


I was thinking to force the replacement of the input, in function.c:6781 
by adding to the condition an i == j check.


Due to this issue, the mainline cannot build ARC uClibc toolchain. I 
suspect that this issue may affect also mips or nios2, but not 100% sure.


Thanks,
Claudiu

Re: Converting to LRA (calling all maintainers)

[Claudiu Zissulescu]

On 16/09/2016 22:37, Segher Boessenkool wrote:

Hi!

Since a few days TARGET_LRA_P defaults to returning "true".  I changed
all in-tree ports to still behave the same as before, which for most
ports means they use old reload always.  All the primary platforms (see
the release criteria, ) now
default to LRA though.

Since one day (hopefully not too very far in the future) we want to
deprecate and eventually remove old reload, all ports that do not want
to risk being removed should be adapted to work with LRA.  New ports
should use LRA always.

I started a wiki page at 
that gives hints on how to go about moving to LRA.  Please add any and
all details and experiences you think can help others, there!

Thanks for listening to this public service announcement,


Segher



Thank you Segher for the wiki. ARC has some experimental support for LRA 
but there are still some issues which needs to be cleaned out. Hopefully 
in the next period, I'll be able to address most of them, leading us to 
have LRA default for our port.



Best,
Claudiu

Re: Support for architectures without hardware interlocks

[Claudiu Zissulescu]

Hi David,

I've worked on a gcc target that was porting an architecture without
hardware interlock support. Basically, you need to emit nop operations
to avoid possible hw conflicts. At the moment, this was done by
patching the gcc scheduler to do so, Another issue to keep is to check
for hardware conflicts across basic-block boundaries. And not the
last, is to prohibit/avoid any instruction stream modification after
scheduler (e.g., peephole optimizations etc.).

Best,
Claudiu

On Fri, Oct 31, 2014 at 8:03 PM, David Kang  wrote:
>
>  Hello,
>
>  I'm working on porting gcc to an architecture without hardware interlock 
> support for floating point unit. I read that instruction latency time can be 
> expressed in machine description file of gcc. I set the latency time of the 
> instructions and built gcc.
> I expected that gcc would put the two dependent instructions apart 
> automatically
> at least as many as the latency time of the first instruction.
> However, my gcc doesn't do that.
> I'm using a little old 4.7.3.
> I also expected that gcc may fill the gap with no-op when it cannot find
> other useful instructions to fill the gap.
> But, I don't see that, either.
>
>  Does gcc support an architecture without hardware interlock automatically?
> Could anyone help me to understand how I can enforce the latency requirements
> of two dependent instructions in gcc?
>
>  I saw that GCC didn't support architectures without hardware interlocks in 
> the gcc mailing list
> which is dated in 2007. (https://gcc.gnu.org/ml/gcc/2007-07/msg00915.html)
> Is it still true?
>
>  Thanks,
>
>  David.
>
> --
> --
> Dr. Dong-In "David" Kang
> Computer Scientist
> USC/ISI

Re: Support for architectures without hardware interlocks

[Claudiu Zissulescu]

Handling the insertion of the nops at the end of RTL pipe needs to
take also care of branch shortening optimizations, and filling delay
slots. Probably for the given context (only FPU ops) may be a doable
approach.

//Claudiu

On Thu, Jan 8, 2015 at 4:28 PM, Joel Sherrill  wrote:
>
> On 1/8/2015 9:01 AM, Eric Botcazou wrote:
>>> I've worked on a gcc target that was porting an architecture without
>>> hardware interlock support. Basically, you need to emit nop operations
>>> to avoid possible hw conflicts. At the moment, this was done by
>>> patching the gcc scheduler to do so, Another issue to keep is to check
>>> for hardware conflicts across basic-block boundaries. And not the
>>> last, is to prohibit/avoid any instruction stream modification after
>>> scheduler (e.g., peephole optimizations etc.).
>> That's an overly complex approach, this usually can be done in a simpler way
>> with a machine-specific pass that runs at the end of the RTL pipeline.
>>
> Isn't this similar to needing to fill a delay slot after a branch
> instruction? My recollection
> is that some SPARC and MIPS have to deal with that.
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>

ARC length attribute patch

[Claudiu Zissulescu]

Hi Joern,

I have a small patch for ARC backend that fixes the value of instruction length 
attribute when the instruction is predicated. Ok to apply?

Thanks,
Claudiu


length.patch
Description: length.patch

RE: ARC length attribute patch

[Claudiu Zissulescu]

Hi Joern,

> >
> > I have a small patch for ARC backend that fixes the value of instruction
> length attribute when the instruction is predicated. Ok to apply?
> Why would the arc_bdr_iscond test have any effect?
> arc_predicate_delay_insns should render the issue moot.
> 
I need to double check the effeteness of arc_bdr_iscond in the new light.

Any feedback for the second part of the patch? I have formatted and added the 
ChangeLog entry as requested. 

//Claudiu


length3.patch
Description: length3.patch

LRA Vs match_scratch

[Claudiu Zissulescu]

Hi guys,

I am trying to get LRA fully working for ARC, but I've got an issue.
Whenever, LRA analyses an instruction having (clobber
(match_scratch:SI 3 "=X, ...)) in its pattern I hit the assert in
lra-constraints.c:4101, and it seems it has to do with the scratch's
'X' constraint.
Do I miss something? Is there any limitation between LRA and scratch
operands having in their alternative 'X' constraint?

Any help appreciated,
Claudiu

Re: LRA Vs match_scratch

[Claudiu Zissulescu]

Hi Segher,

Sorry for the late reply...

Good to know that. I also observed some problems how we define
register classes for ARC. Please allow me to clean it a bit, and then
come back to you with this problem, if it is still there.

Thank you,
Claudiu
On Tue, Sep 11, 2018 at 6:00 PM Segher Boessenkool
 wrote:
>
> Hi Claudiu,
>
> On Tue, Sep 04, 2018 at 11:11:44AM +0200, Claudiu Zissulescu wrote:
> > I am trying to get LRA fully working for ARC, but I've got an issue.
> > Whenever, LRA analyses an instruction having (clobber
> > (match_scratch:SI 3 "=X, ...)) in its pattern I hit the assert in
> > lra-constraints.c:4101, and it seems it has to do with the scratch's
> > 'X' constraint.
> > Do I miss something? Is there any limitation between LRA and scratch
> > operands having in their alternative 'X' constraint?
>
> There are other targets with =X in an alternative for a clobber match_scratch,
> like rs6000, and that does work fine with LRA.  It doesn't hit that assert,
> anyway ;-)
>
> Do you have some debug output to show what is going on here?
>
>
> Segher

Re: Question about ASMCONS

[Claudiu Zissulescu]

Hi all,

This issue still keeps biting me, specially in the glibc upstreaming
process. I have made a bugzilla entry for this
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001) where I also
added my solution for the given issue.

Please can someone help me, or maybe let me know if my patch is acceptable?

Thank you,
Claudiu

On Mon, Dec 19, 2016 at 8:59 PM Claudiu Zissulescu  wrote:
>
> On 19/12/2016 18:06, Segher Boessenkool wrote:
> > Hi Claudiu,
> >
> > On Mon, Dec 19, 2016 at 12:28:54PM +, Claudiu Zissulescu wrote:
> >> I have the following rtl before asmcons pass:
> >>
> >> (insn 8 13 9 2 (set (reg:SI 157 [ list ])
> >> (asm_operands:SI ("") ("=g") 0 [
> >> (const:SI (unspec:SI [
> >> (symbol_ref:SI ("c_const") [flags 0x2]  
> >> )
> >> ] ARC_UNSPEC_GOTOFFPC))
> >> ]
> >>  [
> >> (asm_input:SI ("0") ../t02.c:9)
> >> ]
> >>  [] ../t02.c:9)) ../t02.c:9 -1
> >>  (nil))
> >
> > [ snip ]
> >
> > asmcons eventual does reg_overlap_mentioned_p on the input of the move
> > it created with an input of the asm.  The very first thing
> > reg_overlap_mentioned_p tests for is if the thing is constant.  And it
> > is here, and that makes no sense at all (since it is an output, too!)
> >
> > So how did that happen?
> >
> Right, the reg_overlap_mentioned_p returns zero letting the insn 8
> unchanged.
> The problem is observed in crtstuff.c when compiling __do_globa_dtor_aux
> (line 398). Here it is a short test code:
>
> typedef void (*func_ptr) (void);
> static func_ptr __DTOR_LIST__[1] = { (func_ptr)(-1) };
>
> void foo (int a)
> {
>func_ptr *dtor_list;
>__asm ("" : "=g" (dtor_list) : "0" (__DTOR_LIST__));
>dtor_list[a]();
> }
>
> compiled with -O1 -fpic -mcpu=archs for ARC ;) it will crash somewhere
> in verify_rtx_sharing due to the duplicated const(unspec) thingy.
>
> I was thinking to force the replacement of the input, in function.c:6781
> by adding to the condition an i == j check.
>
> Due to this issue, the mainline cannot build ARC uClibc toolchain. I
> suspect that this issue may affect also mips or nios2, but not 100% sure.
>
> Thanks,
> Claudiu
>

Re: Question about ASMCONS

[Claudiu Zissulescu]

Hi,

Thank you for the quick response, but I still get it with the latest
gcc sources. The error is shown only when the compiler is configured
with all the internal checks in place. Please, can you share with me
the way how you build the toolchain. I am trying to see what I do
wrong...

Thank you,
Claudiu
On Tue, Dec 11, 2018 at 12:34 PM Segher Boessenkool
 wrote:
>
> Hi!
>
> On Tue, Dec 11, 2018 at 12:02:42PM +0200, Claudiu Zissulescu wrote:
> > This issue still keeps biting me, specially in the glibc upstreaming
> > process. I have made a bugzilla entry for this
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001) where I also
> > added my solution for the given issue.
> >
> > Please can someone help me, or maybe let me know if my patch is acceptable?
>
> I have good news for you.  The problem reproduced with my 20181025
> compiler, but between then and now the problem was fixed -- probably
> one of Peter's IRA patches, which dealt with exactly this kind of
> problem :-)
>
>
> Segher

Re: Applying patch to longlong.h

[Claudiu Zissulescu]

Thanks!
Claudiu

On Mon, Apr 1, 2019 at 6:40 PM Jeff Law  wrote:
>
> On 4/1/19 12:57 AM, claz...@gmail.com wrote:
> > Hi,
> >
> > I would like to apply the ARC specific fix for bugzilla 89877 to
> > include/longlong.h file, but I don't know for sure if I am allowed or
> > not. I mention that I am the ARC reviewer.
> If it's in ARC specific bits within longlong.h, then yes, you can just
> go ahead and apply your fix.
>
> Jeff

News entry for ARC

[Claudiu Zissulescu]

Hi Gerald,

I would like to add the following entry to GCC7.x release notes:

ARC
* Add support for ARC HS and ARC EM processors.
* Add support for ARC EM variation found in Intel QuarkSE SoCs.
* Add support for NPS400 ARC700 based cpus.
* Thread Local Storage is now supported by ARC cpus.
* Fix errors for ARC600 when using 32x16 multiplier option.
* Fix PIE for ARC cpus.
* New cpu templates are supported via multilib.

What will be the advisable way to have it in?

Thank you,
Claudiu

RE: News entry for ARC

[Claudiu Zissulescu]

> You need to checkout CVS repository [1], modify files, create a patch.
> Send it to gcc-patches mailing list (with '[wwwdocs]' title) and someone
> will approve the changes.
> 
> Martin

Sent to gcc-patches. Thank you for your quick answer,
Claudiu

Re: Overwhelmed by GCC frustration

[Claudiu Zissulescu]

Maybe better is to use the updated CsIbe repo from github
https://github.com/szeged/csibe. I use it for ARC to track the code
size.

Cheers,
Claudiu

On Fri, Aug 4, 2017 at 11:12 AM, Richard Earnshaw
 wrote:
> On 03/08/17 13:11, Steven Bosscher wrote:
>> On Mon, Jul 31, 2017 at 6:49 PM, Joel Sherrill wrote:
>>
>>>
>>> Long ago, there was a code size regression tester for at least
>>> ARM. Is that still around?
>>
>> There used to be autotesters from CSiBE. Something still appears to
>> exist (http://www.csibe.org/old/) but the last time I tried to run the
>> benchmark, I couldn't get the suite to compile. That was some years
>> ago, perhaps the situation is better nowadays (http://www.csibe.org/
>> without the old, suggests something's changed at some point...).
>>
>> As for "long ago", see also your own reply to
>> https://gcc.gnu.org/ml/gcc/2003-07/msg00111.html :-)
>>
>> Ciao!
>> Steven
>>
>
> CSiBE does still build (but you need -sdt=gnu98).  I build it nightly.
>
> R.

Issues when emitting sjlj dispatch table

[Claudiu Zissulescu]

Hi guys,

I found an ICE when emitting sjlj dispatch table for ARC. Namely, in 
sjlj_emit_dispatch_table() function, we create a dispatch table where the case 
elements are having the high value is set to NULL (except.c:1326). Later, these 
case statements are used by expand_sjlj_dispatch_table() (stmt.c:1006) where we 
create a case list requiring also the high element (stmt.c:1066). This leads to 
an error when we try to compute the high bounds in emit_case_dispatch_table() 
(stmt.c:786), due to the fact that high value is null.

In gcc7.x, we were initializing the high value of case elements in 
sjlj_emit_dispatch_table() with the CASE_LOW. Shouldn't we do the same thing, 
or do I miss something.

A test is attached, the error is visible for ARC backend, the option for the 
compiler should be -O2.

Thanks,
Claudiu


complex_io.ii
Description: complex_io.ii

Backporting ARC patch to gcc7.x

[Claudiu Zissulescu]

Hi,

I would like to backport patch r250097 to gcc7.x branch. It does changes 
libgcc/config.host and gcc/config.gcc for ARC. Do I need to get extra approvals 
for it or I just fallow the wiki on this page 
(https://gcc.gnu.org/wiki/SvnMerge).

Thanks,
Claudiu

RE: Backporting ARC patch to gcc7.x

[Claudiu Zissulescu]

> We've generally considered those clauses under the umbrella of the port
> maintainers.

Thank you for your guidance. I've backported the patch using the gcc guideline:

>svn commit
Sending.
Sendinggcc/ChangeLog
Sendinggcc/config.gcc
Sendinglibgcc/ChangeLog
Sendinglibgcc/config.host
Transmitting file data 
Committed revision 254864.

Thank you,
Claudiu

CFG operation leading to errors

[Claudiu Zissulescu]

Hi,

I've found a potential issue when performing CFG operations for hardware loops.

When a port is using hardware loops (like ARC) makes use of reorg_loops to find 
and analyze loops that end in loop_end instructions. The very same function can 
be set to reorder the cfg such that the loop end occurs after the loop start. 
This task is performed by reoder_loops function which at its turn calls 
cfg_layout_finalize -> fixup_reoreder_chain -> force_nonfallthru_and_redirect 
(cfgrtl.c:1476).
However, the latter is splitting a call and its corresponding CALL_ARG_LOCATION 
note, leading to an assert in dwarf2out_var_location() at dwarf2out.c:26391. 
Thus, I've made a hack which patches the force_nonfallthru_and_redirect() 
function to avoid splitting calls and their note:

diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index ae46908..38a739c 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1626,6 +1626,9 @@ force_nonfallthru_and_redirect (edge e, basic_block 
target, rtx jump_label)
   else
new_head = BB_END (e->src);
   new_head = NEXT_INSN (new_head);
+  if (new_head && NOTE_P (new_head)
+ && NOTE_KIND (new_head) == NOTE_INSN_CALL_ARG_LOCATION)
+   new_head = NEXT_INSN (new_head);
 
   jump_block = create_basic_block (new_head, NULL, e->src);
   jump_block->count = count;

I do not know if this is the way forward and I would like to have your input on 
this subject.

To reproduce the issue one can use ARC backend and the following test code with 
option -O2 -mcpu=arc700 -g :

typedef void Trans_NS_std_new_handler();
void *operator new(unsigned) {
  void *p;
  while (__builtin_expect(p == 0, false)) {
Trans_NS_std_new_handler handler;
try {
  handler();
} catch (int) {
}
  }
  return (void*) 0xdead;
}

Thank you,
Claudiu

Re: Supporting multiple pointer sizes in GCC

[Claudiu Zissulescu]

Hi,

I would try using the named address space for your issue (see
TARGET_ADDR_SPACE_POINTER_MODE). Please check the SPU target for an
implementation example.

Regards,
Claudiu


On Mon, Mar 28, 2011 at 2:14 PM, Jayant R. Sonar
 wrote:
>>?  MIPS has two pointer sizes, but a given compilation (gcc
>> invocation) uses only one of them, it comes from the chosen ABI.
>
> Yes, it looks like MIPS have got 2 ABIs - 32bit and 64bit. The choice
> of the ABI is controlled through a command line option '-march=arch'.
> Therefore in MIPS it doesn't look possible to have 2 pointers of
> different sizes existing simultaneously inside a single executable.
>
> Whereas, what I am looking forward to do is adding some target
> specific data attributes, say data16 and data32. In a simple test case
> I should be able to declare two different pointer variables using these
> attributes as following:
>
> char * ptrABC __attribute__ (data16);
> char * ptrXYZ __attribute__ (data32);
>
> The size of ptrABC should be 16bits and that of ptrXYZ should
> be 32bits.
>
> Will it be possible to do something like this in GCC?
>
> Regards,
> Jayant
>
>
> -Original Message-
> From: Paul Koning [mailto:paul_kon...@dell.com]
> Sent: Friday, March 25, 2011 11:20 PM
> To: DJ Delorie
> Cc: Jayant R. Sonar; gcc@gcc.gnu.org
> Subject: Re: Supporting multiple pointer sizes in GCC
>
>
> On Mar 25, 2011, at 1:37 PM, DJ Delorie wrote:
>
>>
>> "Jayant R. Sonar"  writes:
>>> Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit)
>>> which can co-exist in single compilation unit?
>>> Whether it is supported in GCC now?
>>> Is there any other architecture which has this feature already
>>> implemented?
>>
>> Yes, there are three that I know of - mips64, s390 (tpf), and m32c.
>
> ?  MIPS has two pointer sizes, but a given compilation (gcc invocation) uses 
> only one of them, it comes from the chosen ABI.
>
>        paul
>
>
>

CALL_USED_REGISTERS per function basis

[Claudiu Zissulescu]

Hi,

I want to use a different CALL_USED_REGISTER set per individual
function. The issue here is to inform a caller about the callee
CALL_USED_REGISTERS and save/restore at caller level the possible
altered registers.  This should reduce the number of saved/restored
operation in a function.

Can someone give me some pointers in this direction?

Thank you,
Claudiu

Re: CALL_USED_REGISTERS per function basis

[Claudiu Zissulescu]

Hi,

I am thinking (as I am not familiar with IRA) to the following
alternative to your solution:

I set to zero all CALL_USED_REGISTERS (except the fixed regs), and
then in the expand_call I set CALL_INSN_FUNCTION_USAGE to the list of
clobbered registers (given by attribute attached to a function
declaration).  Then, I should be able to achieve the same effect
without touching the IRA.

Additionally, a global variable will hold the "default"
call_used_registers for the cases when the function call used regs
attribute is not set.

What do you think about this approach?

Best regards,
Claudiu

Re: BImode is treated as normal byte-wide mode and causes bug.

[Claudiu Zissulescu]

Hi,

Why don't you use a define_insn "zero_extendbisi2" which generates
your conversion instruction. You can also use a define_insn_and_split
if you have multiple instructions to generate. The
define_insn_and_split should take place after reload is completed.
Hence, you will avoid working on subregs.

Best,
Claudiu

On Fri, Dec 10, 2010 at 10:58 AM, Bingfeng Mei  wrote:
>
> Hi,
> I am investigating a bug in our target port. It is
> due to following optimization done by combine pass.
>
> (zero_extend:SI (reg:BI 120))
>
> is transformed to
>
> (and:SI (subreg:SI (reg:BI 120) 0)
>    (const_int 255 [0xff]))
>
> in expand_compound_operation (combine.c), where BImode is
> just treated as a byte-wide mode.
>
> In machmode.def, BImode is defined as FRACTIONAL_INT_MODE (BI, 1, 1).
> But the precision field is not used at all here.
>
> Even after I hacked the code to bypass the transformation.
>
> (subreg:QI (zero_extend:SI (reg:BI 120)) 0)
>
> is still transformed to
> (subreg:QI (reg:BI 120) 0))
>
> in simplify_subreg. This is wrong because the higher bits
> of paradoxical subreg is undefined here, not zeros.
>
> Grep GET_MODE_PRECISION returns not many results. It seems
> that many rtx optimization functions don't consider
> FRACTIONAL_INT_MODE at all. If that is the case, we should
> document that limitations (or maybe I missed it).
>
> We need zero_extend BImode to model behaviour of moving
> lowest bit of predicate register into general register.
>
> Cheers,
> Bingfeng
>

Issues with GCSE pre step and double hard registers

[Claudiu Zissulescu]

Hi,

Our ARC processor has a multiplication operation that returns a 64 bit result 
into a fixed register pair named  like this:

mlo:DI=zero_extend(r159:SI)*sign_extend(r181:SI)

The GCSE rtl pre step has some difficulties to handle hard register pair 
information. To exemplify my problem please see the following example:

   18: mlo:DI=zero_extend(r159:SI)*sign_extend(r170:SI)
  REG_EQUAL zero_extend(r159:SI)*0xcccd
  REG_DEAD r170:SI
  REG_UNUSED mlo:SI

   20: r168:SI=mhi:SI 0>>0x3
  REG_DEAD mhi:SI
  REG_EQUAL udiv(r159:SI,0xa)



   36: mlo:DI=zero_extend(r159:SI)*sign_extend(r181:SI)
  REG_EQUAL zero_extend(r159:SI)*0xcccd
  REG_DEAD r181:SI
  REG_UNUSED mlo:SI

   38: r179:SI=mhi:SI 0>>0x3
  REG_DEAD mhi:SI
  REG_EQUAL udiv(r159:SI,0xa)

The "reg_avail_info" structure misses information about mhi register. The mlo 
information, the first register in the register pair, the information is 
correctly computed.  Due to the missing mhi information,  the instruction 38 is 
considered an anticipated expression (due to faulty return of function 
oprs_unchanged_p() ). This leads to removal of instruction 38 ( gcse via insn 
20) and all the dependent instructions.

A possible solution is to check if reg_avail_info holds initialized data in 
oprs_unchanged_p() function, avoiding false positive returns, like this:

--- a/gcc/gcse.c
+++ b/gcc/gcse.c
@@ -881,6 +881,8 @@ oprs_unchanged_p (const_rtx x, const_rtx insn, int avail_p)
   {
struct reg_avail_info *info = ®_avail_info[REGNO (x)];

+   if (info->last_bb == NULL)
+ return 0;
if (info->last_bb != current_bb)
  return 1;
if (avail_p)


Please let me know if this is an acceptable solution for my issue.

Thank you,
Claudiu Zissulescu

RE: Issues with GCSE pre step and double hard registers

[Claudiu Zissulescu]

> I don't think this is not the right fix for the problem. GCSE doesn't handle
> expressions containing hard registers, oprs_unchanged_p should never even
> see expressions involving hard registers.

I was afraid of this one.

> 
> What is the expression that is recorded as anticipated in insn 38? Is it 
> "mho:SI
> 0>>0x3" or "udiv(r159:SI,0xa)" from the REG_EQUAL note?
> 

Instruction 38. 

As far as I can see, a solution is to use a split pattern after register 
allocation to describe the multiplication (now it is done in the expand). 
Another one, is to force the gcse to check the regnotes (REG_EQUAL) rather than 
the instruction itself.

Best,
Claudiu

RE: Issues with GCSE pre step and double hard registers

[Claudiu Zissulescu]

> What is the expression that is recorded as anticipated in insn 38? Is it 
> "mho:SI
> 0>>0x3" or "udiv(r159:SI,0xa)" from the REG_EQUAL note?

Just to be clear, the anticipated operation is "mho:SI 0>>9x31".

//Claudiu

VREGS fails to handle subreg of mem

[Claudiu Zissulescu]

Hi,

In our ARC port, we found the following situation after expand:

(insn 23 22 24 5 (set (reg:SI 176)
(subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-vars)
(const_int -268 [0xfef4])) [3 
tmpoutst.st_size+0 S8 A32]) 4)) t02.c:64 -1
 (nil))

The virtual-stack-vars should be handled by GCC's VREGS step, in 
instantiate_virtual_regs_in_insn(). However, this is not happening as the 
subroutine is not designed to handle subregs of a mem. As a consequence, 
virtual-stack-vars is not eliminated, and the compilation fails later on. To 
solve this issue, I am proposing the attached patch on vregs, that implements 
handling of such situation by instantiate_virtual_regs_in_insn().

Can you please let me know if this is an acceptable solution for the given 
issue?

//Claudiu


function.c.patch
Description: function.c.patch

RE: VREGS fails to handle subreg of mem

[Claudiu Zissulescu]

Thank you for the feedback. I did found the issue in mode_dependent_address_p 
hook.

//Claudiu

> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Monday, March 31, 2014 10:21 PM
> To: Claudiu Zissulescu
> Cc: gcc@gcc.gnu.org; Francois Bedard; claz...@gmail.com
> Subject: Re: VREGS fails to handle subreg of mem
> 
> > In our ARC port, we found the following situation after expand:
> >
> > (insn 23 22 24 5 (set (reg:SI 176)
> > (subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-vars)
> > (const_int -268 [0xfef4])) [3
> > tmpoutst.st_size+0 S8 A32]) 4)) t02.c:64 -1 (nil))
> >
> > The virtual-stack-vars should be handled by GCC's VREGS step, in
> > instantiate_virtual_regs_in_insn(). However, this is not happening as
> > the subroutine is not designed to handle subregs of a mem. As a
> > consequence, virtual-stack-vars is not eliminated, and the compilation fails
> later on.
> > To solve this issue, I am proposing the attached patch on vregs, that
> > implements handling of such situation by
> > instantiate_virtual_regs_in_insn().
> >
> > Can you please let me know if this is an acceptable solution for the
> > given issue?
> 
> Very likely not, there should be no SUBREGs of MEMs after expand.
> 
> --
> Eric Botcazou

Re: Claudiu Zissulescu appointed ARC Co-Maintainer

[Claudiu Zissulescu via Gcc]

Thank you for your support,
Claudiu

From: David Edelsohn 
Sent: Sunday, November 29, 2020 9:47 PM
To: Claudiu Zissulescu ; gcc@gcc.gnu.org 
Subject: Claudiu Zissulescu appointed ARC Co-Maintainer

I am pleased to announce that the GCC Steering Committee has
appointed Claudiu Zissulescu as ARC Co-Maintainer.

Please join me in congratulating Claudiu on his new role.
Claudiu, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: GCC arc port defaults to -fcommon

[Claudiu Zissulescu via Gcc]

The fno-common option is indeed related to the use of small-data. However, the 
small data is only used for baremetal applications, and it shouldn't be used 
for  linux toolchain.

To me Richard's patch looks alright.
Thanks,
Claudiu


From: Richard Biener 
Sent: Wednesday, July 7, 2021 12:58 PM
To: Florian Weimer 
Cc: GCC Development ; Joern Wolfgang Rennecke 
; Claudiu Zissulescu 
Subject: Re: GCC arc port defaults to -fcommon

On Wed, Jul 7, 2021 at 11:56 AM Richard Biener
 wrote:
>
> On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc  
> wrote:
> >
> > It seems to me that the arc port still defaults to -fcommon, presumably
> > due to this in gcc/common/config/arc/arc-common.c:
> >
> > static void
> > arc_option_init_struct (struct gcc_options *opts)
> > {
> >   opts->x_flag_no_common = 255; /* Mark as not user-initialized.  */
> >
> >   /* Which cpu we're compiling for (ARC600, ARC601, ARC700, ARCv2).  */
> >   arc_cpu = PROCESSOR_NONE;
> > }
> >
> > Is that really necessary?  Is -fno-common broken on arc?
>
> It seems arc has -fcommon dependent on !TARGET_NO_SDATA_SET
> but it should use global_options_set.x_flag_no_common instead of
> such magic value.

So sth like this (untested):

diff --git a/gcc/common/config/arc/arc-common.c
b/gcc/common/config/arc/arc-common.c
index 6a119029616..c8ac7471744 100644
--- a/gcc/common/config/arc/arc-common.c
+++ b/gcc/common/config/arc/arc-common.c
@@ -32,8 +32,6 @@ along with GCC; see the file COPYING3.  If not see
 static void
 arc_option_init_struct (struct gcc_options *opts)
 {
-  opts->x_flag_no_common = 255; /* Mark as not user-initialized.  */
-
   /* Which cpu we're compiling for (ARC600, ARC601, ARC700, ARCv2).  */
   arc_cpu = PROCESSOR_NONE;
 }
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 69f6ae464e1..b9097b11835 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -1440,7 +1440,7 @@ arc_override_options (void)
   if (flag_pic)
 target_flags |= MASK_NO_SDATA_SET;

-  if (flag_no_common == 255)
+  if (!global_options_set.x_flag_no_common)
 flag_no_common = !TARGET_NO_SDATA_SET;

   /* Check for small data option */


> > I plan to switch glibc to build with -fno-common unconditionally, for
> > all GCC versions and architectures, and I wonder if that would be a
> > blocker.
> >
> > Thanks,
> > Florian
> >

Re: GCC arc port defaults to -fcommon

[Claudiu Zissulescu via Gcc]

Hi,

I have quickly tested the next patch, and it looks like everything is alright. 
In the end we don't really need to temper with fcommon.


diff --git a/gcc/common/config/arc/arc-common.c 
b/gcc/common/config/arc/arc-common.c
index 6a1190296167..3b36d09997c7 100644
--- a/gcc/common/config/arc/arc-common.c
+++ b/gcc/common/config/arc/arc-common.c
@@ -30,10 +30,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "flags.h"

 static void
-arc_option_init_struct (struct gcc_options *opts)
+arc_option_init_struct (struct gcc_options *opts ATTRIBUTE_UNUSED)
 {
-  opts->x_flag_no_common = 255; /* Mark as not user-initialized.  */
-
   /* Which cpu we're compiling for (ARC600, ARC601, ARC700, ARCv2).  */
   arc_cpu = PROCESSOR_NONE;
 }
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 584783f2fb88..5f1d2ffd3995 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -1449,9 +1449,6 @@ arc_override_options (void)
   target_flags |= MASK_NO_SDATA_SET;
 }

-  if (flag_no_common == 255)
-flag_no_common = !TARGET_NO_SDATA_SET;
-
   /* Check for small data option */
   if (!global_options_set.x_g_switch_value && !TARGET_NO_SDATA_SET)
 g_switch_value = TARGET_LL64 ? 8 : 4;




From: Florian Weimer 
Sent: Wednesday, July 7, 2021 1:06 PM
To: Richard Biener 
Cc: GCC Development ; Joern Wolfgang Rennecke 
; Claudiu Zissulescu 
Subject: Re: GCC arc port defaults to -fcommon

* Richard Biener:

> On Wed, Jul 7, 2021 at 11:56 AM Richard Biener
>  wrote:
>>
>> On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc  
>> wrote:
>> >
>> > It seems to me that the arc port still defaults to -fcommon, presumably
>> > due to this in gcc/common/config/arc/arc-common.c:
>> >
>> > static void
>> > arc_option_init_struct (struct gcc_options *opts)
>> > {
>> >   opts->x_flag_no_common = 255; /* Mark as not user-initialized.  */
>> >
>> >   /* Which cpu we're compiling for (ARC600, ARC601, ARC700, ARCv2).  */
>> >   arc_cpu = PROCESSOR_NONE;
>> > }
>> >
>> > Is that really necessary?  Is -fno-common broken on arc?
>>
>> It seems arc has -fcommon dependent on !TARGET_NO_SDATA_SET
>> but it should use global_options_set.x_flag_no_common instead of
>> such magic value.
>
> So sth like this (untested):
>
> diff --git a/gcc/common/config/arc/arc-common.c
> b/gcc/common/config/arc/arc-common.c
> index 6a119029616..c8ac7471744 100644
> --- a/gcc/common/config/arc/arc-common.c
> +++ b/gcc/common/config/arc/arc-common.c
> @@ -32,8 +32,6 @@ along with GCC; see the file COPYING3.  If not see
>  static void
>  arc_option_init_struct (struct gcc_options *opts)
>  {
> -  opts->x_flag_no_common = 255; /* Mark as not user-initialized.  */
> -
>/* Which cpu we're compiling for (ARC600, ARC601, ARC700, ARCv2).  */
>arc_cpu = PROCESSOR_NONE;
>  }
> diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> index 69f6ae464e1..b9097b11835 100644
> --- a/gcc/config/arc/arc.c
> +++ b/gcc/config/arc/arc.c
> @@ -1440,7 +1440,7 @@ arc_override_options (void)
>if (flag_pic)
>  target_flags |= MASK_NO_SDATA_SET;
>
> -  if (flag_no_common == 255)
> +  if (!global_options_set.x_flag_no_common)
>  flag_no_common = !TARGET_NO_SDATA_SET;
>
>/* Check for small data option */

But this means that arc still defaults to -fcommon with this change,
right?

Thanks,
Florian

Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

Hi,

I've stumbled over a potential issue related to Dataflow analysis,
and maybe you can help me with it. It can be reproduced for AARCH64
but other architectures are affected as well.

I have the next snip before CSE1 pass:

(insn 14 11 15 3 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [ bytes ])
(const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
 (nil))
(jump_insn 15 14 16 3 (set (pc)
(if_then_else (gtu (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 27)
(pc))) "bad_cc.c":11:8 15 {condjump}
 (int_list:REG_BR_PROB 955630228 (nil))
 -> 27)

(note 16 15 17 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 17 16 18 4 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [ bytes ])
(const_int 8 [0x8]))) "bad_cc.c":12:10 406 {cmpsi}
 (nil))
(jump_insn 18 17 19 4 (set (pc)
(if_then_else (eq (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "bad_cc.c":12:10 15 {condjump}
 (int_list:REG_BR_PROB 365072228 (nil))
 -> 34)

The CSE1 optimizes the second comparison (i.e., INSN 17) as it is similar with
the one from INSN 14.

However, after this optimization I get the CC reg being dead after
JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
from fwprop1:

(insn 14 11 15 3 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [ bytes ])
(const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
 (nil))
(jump_insn 15 14 16 3 (set (pc)
(if_then_else (gtu (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 27)
(pc))) "bad_cc.c":11:8 15 {condjump}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 955630228 (nil)))
 -> 27)
(note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn 18 16 19 4 (set (pc)
(if_then_else (eq (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "bad_cc.c":12:10 15 {condjump}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 365072228 (nil)))
 -> 34)

Please observe the REG_DEAD note on the both jump instructions.

I see this behaviour in GCC 12.2.1 release for AARCH64, but I cannot
see it for GCC 10.x

A test code snip is attached, and it needs to be compiled with aarch64
backend using -Os option.
typedef unsigned int uint32_t;
typedef unsigned char uint8_t;

void foo (uint32_t *src, uint8_t *c, uint32_t bytes)
{
  uint8_t *ctarget;

  for (;;) {
c[0] = src[0] & 0xff;

if (bytes <= 8) {
  if (bytes < 8) {
	 ctarget[4] = c[4];
  }
  return;
}

bytes -= 8;
c += 8;
  }
}

Re: Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

Hi Eric,
The problem shows in loop-doloop.c when I introduce a loop end pattern
that replaces the first jump instruction (JUMP_INSN 15) with a pattern
that clobbers CC reg. However, the DF doesn't look like it works as
the doloop step cannot find the CC reg alive. Please see
loop-doloop.c:766. Hence, it introduces the doloop_end patterns, and
renders the compare instruction (INSN 14) dead code. leading to
errors.

Thanks,
Claudiu

On Thu, Dec 8, 2022 at 1:33 PM Eric Botcazou  wrote:
>
> > However, after this optimization I get the CC reg being dead after
> > JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
> > from fwprop1:
> >
> > (insn 14 11 15 3 (set (reg:CC 66 cc)
> > (compare:CC (reg/v:SI 98 [ bytes ])
> > (const_int 8 [0x8]))) "bad_cc.c":11:8 406 {cmpsi}
> >  (nil))
> > (jump_insn 15 14 16 3 (set (pc)
> > (if_then_else (gtu (reg:CC 66 cc)
> > (const_int 0 [0]))
> > (label_ref 27)
> > (pc))) "bad_cc.c":11:8 15 {condjump}
> >  (expr_list:REG_DEAD (reg:CC 66 cc)
> > (int_list:REG_BR_PROB 955630228 (nil)))
> >  -> 27)
> > (note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
> > (jump_insn 18 16 19 4 (set (pc)
> > (if_then_else (eq (reg:CC 66 cc)
> > (const_int 0 [0]))
> > (label_ref:DI 34)
> > (pc))) "bad_cc.c":12:10 15 {condjump}
> >  (expr_list:REG_DEAD (reg:CC 66 cc)
> > (int_list:REG_BR_PROB 365072228 (nil)))
> >  -> 34)
> >
> > Please observe the REG_DEAD note on the both jump instructions.
>
> Passes that consume REG_DEAD/REG_UNUSED notes need to recompute them
> explicitly, they are not updated on the fly.
>
> --
> Eric Botcazou
>
>

Re: Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

It looks like that. The df_analyze_loop is only looking at the loop
BBs, and it is not clear for me if df_analyze_loop is required to have
all the df_live_outs correctly computed or not. Do you know if it is
true?

If the df_analyze_loop is not supposed to compute all the df_live_outs
correctly, then the error resides in how loop-doloop is using the
iv_analysis_loop_init().

Thank you for your help,
Claudiu

On Tue, Dec 13, 2022 at 10:41 AM Eric Botcazou  wrote:
>
> > The problem shows in loop-doloop.c when I introduce a loop end pattern
> > that replaces the first jump instruction (JUMP_INSN 15) with a pattern
> > that clobbers CC reg. However, the DF doesn't look like it works as
> > the doloop step cannot find the CC reg alive. Please see
> > loop-doloop.c:766. Hence, it introduces the doloop_end patterns, and
> > renders the compare instruction (INSN 14) dead code. leading to
> > errors.
>
> So df_get_live_out does not contain the CC register?  iv_analysis_loop_init
> only performs a local update of the DF information, maybe it does not cover
> the basic block containing insn 14 and 15?
>
> --
> Eric Botcazou
>
>

Re: Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

UPDATE:
The df_analyze_loop is calling the df_set_blocks. Thus, the analysis
behaves as if the function only contains those blocks and any edges
that occur directly between the blocks in the set (see df-core.cc).
This said, the loop-doloop behaves faulty at loop-doloop.cc:772 as the
df_get_lives_out (loop_end) is not computed correctly.

A possible solution is to include in the blocks_to_analyze the missing
basic blocks, something like:

diff --git a/gcc/df-core.cc b/gcc/df-core.cc
index a901b84878f..d7059c188b2 100644
--- a/gcc/df-core.cc
+++ b/gcc/df-core.cc
@@ -1437,7 +1437,15 @@ df_analyze_loop (class loop *loop)
   df_set_blocks (blocks);
   BITMAP_FREE (blocks);

-  df_analyze_1 ();
+  /* Add the loop's header successor bbs too.  */
+  edge e;
+  edge_iterator ei;
+  FOR_EACH_EDGE (e, ei, loop->header->succs)
+bitmap_set_bit (df->blocks_to_analyze, e->dest->index);
+
+  if (dump_file)
+debug_bitmap_file (dump_file, df->blocks_to_analyze);
+  df_analyze ();
 }

What do you think,
Claudiu

On Tue, Dec 13, 2022 at 2:30 PM Claudiu Zissulescu Ianculescu
 wrote:
>
> It looks like that. The df_analyze_loop is only looking at the loop
> BBs, and it is not clear for me if df_analyze_loop is required to have
> all the df_live_outs correctly computed or not. Do you know if it is
> true?
>
> If the df_analyze_loop is not supposed to compute all the df_live_outs
> correctly, then the error resides in how loop-doloop is using the
> iv_analysis_loop_init().
>
> Thank you for your help,
> Claudiu
>
> On Tue, Dec 13, 2022 at 10:41 AM Eric Botcazou  wrote:
> >
> > > The problem shows in loop-doloop.c when I introduce a loop end pattern
> > > that replaces the first jump instruction (JUMP_INSN 15) with a pattern
> > > that clobbers CC reg. However, the DF doesn't look like it works as
> > > the doloop step cannot find the CC reg alive. Please see
> > > loop-doloop.c:766. Hence, it introduces the doloop_end patterns, and
> > > renders the compare instruction (INSN 14) dead code. leading to
> > > errors.
> >
> > So df_get_live_out does not contain the CC register?  iv_analysis_loop_init
> > only performs a local update of the DF information, maybe it does not cover
> > the basic block containing insn 14 and 15?
> >
> > --
> > Eric Botcazou
> >
> >

Re: Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

>
> Maybe you want to iterate over the loops exit edges and include their 
> destination block instead?
>

This is better approach, let me try it and I will be back to you.

Thanks,
Claudiu

Re: Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

I have update the fix to this one:

diff --git a/gcc/df-core.cc b/gcc/df-core.cc
index a901b84878f..cc6383990a1 100644
--- a/gcc/df-core.cc
+++ b/gcc/df-core.cc
@@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop)
   df_set_blocks (blocks);
   BITMAP_FREE (blocks);

-  df_analyze_1 ();
+  /* Iterate over loop's exit edges and add theirs destinations BB
+ indexes.  */
+  struct loop_exit *exit;
+  for (exit = loop->exits->next; exit->e; exit = exit->next)
+bitmap_set_bit (df->blocks_to_analyze, exit->e->dest->index);
+
+  if (dump_file)
+debug_bitmap_file (dump_file, df->blocks_to_analyze);
+
+  df_analyze ();
 }

I still need to validate it for x86

Best,
Claudiu

On Tue, Dec 13, 2022 at 7:38 PM Claudiu Zissulescu Ianculescu
 wrote:
>
> >
> > Maybe you want to iterate over the loops exit edges and include their 
> > destination block instead?
> >
>
> This is better approach, let me try it and I will be back to you.
>
> Thanks,
> Claudiu

Re: Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

Hi Richard,

Sorry for my misunderstanding. I am calling the df_analyze() instead
of df_analyze1() at the end. Shouldn't df_analyze take care and
compute the correct postorder  (df-core.cc:1273) ?

Thank you,
Claudiu

On Wed, Dec 14, 2022 at 1:06 PM Richard Biener
 wrote:
>
> On Wed, Dec 14, 2022 at 11:37 AM Claudiu Zissulescu Ianculescu
>  wrote:
> >
> > I have update the fix to this one:
> >
> > diff --git a/gcc/df-core.cc b/gcc/df-core.cc
> > index a901b84878f..cc6383990a1 100644
> > --- a/gcc/df-core.cc
> > +++ b/gcc/df-core.cc
> > @@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop)
> >df_set_blocks (blocks);
> >BITMAP_FREE (blocks);
> >
> > -  df_analyze_1 ();
> > +  /* Iterate over loop's exit edges and add theirs destinations BB
> > + indexes.  */
> > +  struct loop_exit *exit;
> > +  for (exit = loop->exits->next; exit->e; exit = exit->next)
> > +bitmap_set_bit (df->blocks_to_analyze, exit->e->dest->index);
>
> I think you want to adjust the local 'blocks' bitmap passed to df_set_blocks.
> There's also the issue that the computed postorder doesn't include the new
> blocks and thus the computation will likely be invalid?
>
> > +
> > +  if (dump_file)
> > +debug_bitmap_file (dump_file, df->blocks_to_analyze);
> > +
> > +  df_analyze ();
> >  }
> >
> > I still need to validate it for x86
> >
> > Best,
> > Claudiu
> >
> > On Tue, Dec 13, 2022 at 7:38 PM Claudiu Zissulescu Ianculescu
> >  wrote:
> > >
> > > >
> > > > Maybe you want to iterate over the loops exit edges and include their 
> > > > destination block instead?
> > > >
> > >
> > > This is better approach, let me try it and I will be back to you.
> > >
> > > Thanks,
> > > Claudiu

Fwd: Possible regression in DF analysis

[Claudiu Zissulescu Ianculescu via Gcc]

+ gcc mailing list

-- Forwarded message -
From: Claudiu Zissulescu Ianculescu 
Date: Tue, Dec 20, 2022 at 2:31 PM
Subject: Re: Possible regression in DF analysis
To: Jeff Law 


Hi Jeff,

> Or is that the core of the problem -- that life analysis is inaccurate
> or unavailable?
>
The life analysis is not accurate/missing and loop-doloop check is not
performed, leading in inserting the doloop end pattern when it
shouldn't.
The issue is how df_analyse_loop sets the df problem subset, not
including the destination BB from the exit edges of a loop. I am
looking now how loop_post_order_compute and
loop_inverted_post_order_compute can include those missing BBs too.

Thanks,
Claudiu

Re: How to implement Native TLS for a specific platform?

[Claudiu Zissulescu Ianculescu via Gcc]

Hi Julian,

You can check how we did it for ARC. In a nutshell, you need to define
HAVS_AS_TLS macro, you need to legitimize the new TLS address and
calls. Please have a look in arc.cc and search for TLS, also use git
blame to see the original patches. Of course, there are different ways
to implement TLS, in ARC is the simplest solution. Also, u need to
hack the assembler, linker and the OS for a full implementation.

Cheers,
Claudiu

On Tue, Jul 9, 2024 at 7:14 PM Julian Waters via Gcc  wrote:
>
> Hi all,
>
> I'm currently trying to implement Native TLS on a platform that gcc uses
> emutls for at the moment, but I can't seem to figure out where and how to
> implement it. I have a rough idea of the assembly required for TLS on this
> platform, but I don't know where to plug it in to the compiler to make it
> work. Could someone point me in the right direction for implementing TLS
> for a platform that doesn't have it implemented at the moment?
>
> I'm aware that I am being vague as to which platform I want to implement it
> for. It's a platform that is likely low priority in the eyes of most gcc
> maintainers, so I'm deliberately avoiding mentioning what platform it is so
> I don't get crickets for a reply :)
>
> best regards,
> Julian

Re: How to implement Native TLS for a specific platform?

[Claudiu Zissulescu Ianculescu via Gcc]

Hi Julian,

I hope you have Ulrich's document about TLS, if not please google it:
"ELF Handling for Thread-Local Storage - Ulrich Drepper"

In ARC, I used unspec constructions to emit TLS addresses. If you
wanna simplify it, in the legitimzie_tls_address you can only
implement the most general case, namely TLS_GLOBAL_DYNAMIC, and all
the others to fall back to it. For TLS, you need to reserve a tls
register which will hold the tls pointer (in arc is a register holded
by arc_tp_regno variable, but in ur case u can fix it).
U can use the tls examples in the gcc's dejagnu test folder, compile
arc backend and check the output assembly to see how it works.
In case of ARC, the global dynamic model generates two relocs:

   add   r0,pcl,@x@tlsgd# R_ARC_TLS_GD_GOT x
   bl@__tls_get_addr@plt# R_ARC_S21_PCREL_PLT __tls_get_addr
   # Address of x in r0

where __tls_get_addr is a function provided by the OS which will
return the address of variable x in r0 (return reg). You should
already have the PLT reloc, and you need to implement the TLS_GD_GOT
reloc to GOT table. In GOT table you need additionally two relocs:
GOT[n]  R_ARC_TLS_DTPMOD x
GOT[n+1]  R_ARC_TLS_DTPOFF x

I hope this may clarify it a bit, cheers,
Claudiu

On Thu, Jul 18, 2024 at 12:43 PM Julian Waters via Gcc  wrote:
>
> I guess I'll just say what platform I want to implement this for, since the
> roundabout way of talking about it is probably confusing to everyone. It's
> Windows, and hopefully implementing TLS for it should be relatively easier
> since there is only 1 TLS model on Windows
>
> best regards,
> Julian
>
> On Thu, Jul 18, 2024 at 5:39 PM Julian Waters 
> wrote:
>
> > Hi Claudiu,
> >
> > Thanks for the tip, I've since looked at and drawn inspiration from
> > arc.cc. The main issue I have now is how to implement the code in
> > legitimize_tls_address under i386.cc and the corresponding i386.md machine
> > description file to get the following assembly for a TLS read (Assuming
> > that local is the name of the thread local variable, that the last mov
> > depends on the size of the variable, since it would be movq if it was an 8
> > byte variable, that rscratch refers to scratch registers, and that
> > rscratch1 holds the read TLS value at the end of the operation):
> >
> > movl _tls_index(%rip), %rscratch1
> > movq %gs:88, %rscratch2
> > movq (%rscratch2, %rscratch1, 8), %rscratch1
> > movl local@SECREL32(%rscratch1), %rscratch1
> >
> > With some reference from the arc.cc code and another (unofficial) patch
> > for the platform that I want to implement TLS for, I've managed a half
> > finished implementation of TLS, but the final blocker so to speak is my
> > lack of understanding on how the RTL manipulating code in
> > legitimize_tls_address works. If you have any pointers on how to manipulate
> > RTL to get the assembly required as seen above, I would be very much
> > grateful :)
> >
> > best regards,
> > Julian
> >
> > On Tue, Jul 16, 2024 at 8:16 PM Claudiu Zissulescu Ianculescu <
> > claz...@gmail.com> wrote:
> >
> >> Hi Julian,
> >>
> >> You can check how we did it for ARC. In a nutshell, you need to define
> >> HAVS_AS_TLS macro, you need to legitimize the new TLS address and
> >> calls. Please have a look in arc.cc and search for TLS, also use git
> >> blame to see the original patches. Of course, there are different ways
> >> to implement TLS, in ARC is the simplest solution. Also, u need to
> >> hack the assembler, linker and the OS for a full implementation.
> >>
> >> Cheers,
> >> Claudiu
> >>
> >> On Tue, Jul 9, 2024 at 7:14 PM Julian Waters via Gcc 
> >> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > I'm currently trying to implement Native TLS on a platform that gcc uses
> >> > emutls for at the moment, but I can't seem to figure out where and how
> >> to
> >> > implement it. I have a rough idea of the assembly required for TLS on
> >> this
> >> > platform, but I don't know where to plug it in to the compiler to make
> >> it
> >> > work. Could someone point me in the right direction for implementing TLS
> >> > for a platform that doesn't have it implemented at the moment?
> >> >
> >> > I'm aware that I am being vague as to which platform I want to
> >> implement it
> >> > for. It's a platform that is likely low priority in the eyes of most gcc
> >> > maintainers, so I'm deliberately avoiding mentioning what platform it
> >> is so
> >> > I don't get crickets for a reply :)
> >> >
> >> > best regards,
> >> > Julian
> >>
> >