Possible issue with using LAST_INSN_CODE

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

Re: Possible issue with using LAST_INSN_CODE

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_CO

Write after approval question

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

RE: Write after approval question

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.u

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

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; f

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

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-f

ARC's pending patches

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-patche

RE: ARC's pending patches

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

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

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

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

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.,

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

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

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

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 su

Question about ASMCONS

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))

Re: Question about ASMCONS

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 [

Re: Converting to LRA (calling all maintainers)

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,

Re: Support for architectures without hardware interlocks

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

Re: Support for architectures without hardware interlocks

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:

ARC length attribute patch

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

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 th

LRA Vs match_scratch

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 somet

Re: LRA Vs match_scratch

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 "=

Re: Question about ASMCONS

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 befor

Re: Question about ASMCONS

, 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

Re: Applying patch to longlong.h

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 t

News entry for ARC

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

RE: News entry for ARC

> 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

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 Sherri

Issues when emitting sjlj dispatch table

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() (

Backporting ARC patch to gcc7.x

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

> 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 Sending

CFG operation leading to errors

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 oc

Re: Supporting multiple pointer sizes in GCC

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 >

CALL_USED_REGISTERS per function basis

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 so

Re: CALL_USED_REGISTERS per function basis

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

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

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 subreg

Issues with GCSE pre step and double hard registers

ptable solution for my issue. Thank you, Claudiu Zissulescu

RE: Issues with GCSE pre step and double hard registers

> 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?

RE: Issues with GCSE pre step and double hard registers

> 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

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)) Th

RE: VREGS fails to handle subreg of mem

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; Franco

Re: Claudiu Zissulescu appointed ARC Co-Maintainer

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

Re: GCC arc port defaults to -fcommon

ener 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 v

Re: GCC arc port defaults to -fcommon

&& !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 * R

Possible regression in DF analysis

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 [

Re: Possible regression in DF analysis

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. Henc

Re: Possible regression in DF analysis

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, th

Re: Possible regression in DF analysis

->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 > BB

Re: Possible regression in DF analysis

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

ug_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 > &

Re: Possible regression in DF analysis

ec 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 >

Fwd: Possible regression in DF analysis

+ 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 unava

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

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 impleme

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

mize_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 Ianc