Re: Pointer semantics in GIMPLE

On Thu, 20 Mar 2025, Richard Biener wrote: Pointer arithmetic -- POINTER_DIFF_EXPR --- Subtracting a pointer q from a pointer p is done using POINTER_DIFF_EXPR. * It is UB if the difference does not fit in a signed integer with the same precision as the

Re: Pointer semantics in GIMPLE

On Fri, 21 Mar 2025, Richard Biener wrote: Issues -- The semantics I've described above result in many reports of miscompilations that I haven't reported yet. As mentioned earlier, the vectorizer can use POINTER_PLUS_EXPR to generate pointers that extend up to a vector length past the objec

Re: Pointer semantics in GIMPLE

On Fri, Mar 21, 2025 at 12:27 AM Krister Walfridsson wrote: > > On Thu, 20 Mar 2025, Richard Biener wrote: > > >> Pointer arithmetic -- POINTER_DIFF_EXPR > >> --- > >> Subtracting a pointer q from a pointer p is done using POINTER_DIFF_EXPR. > >> * It is UB if

Re: Pointer semantics in GIMPLE

On Thu, Mar 20, 2025 at 2:05 AM Krister Walfridsson via Gcc wrote: > > I'm working on ensuring that the GIMPLE semantics used by smtgcc are > correct, and I have a lot of questions about the details. I'll be sending > a series of emails with these questions. This first one

Re: Question about optimizing dynamic_cast call in C++ at GIMPLE Level

wever, I am not very familiar with GCC source code at present, and that is the reason why I am asking for help here. Thanks, Hanke Zhang Florian Weimer 于2025年1月18日周六 20:50写道： > > * Hanke Zhang via Gcc: > > > I have recently been delving into optimizing dynamic_cast calls in C++ > &

Re: Question about optimizing dynamic_cast call in C++ at GIMPLE Level

* Hanke Zhang via Gcc: > I have recently been delving into optimizing dynamic_cast calls in C++ > within the context of GIMPLE code. In particular, for scenarios > involving single inheritance, I'm aiming to convert the following > code: > > _1 = __dynamic_cas

Question about optimizing dynamic_cast call in C++ at GIMPLE Level

Hi, I have recently been delving into optimizing dynamic_cast calls in C++ within the context of GIMPLE code. In particular, for scenarios involving single inheritance, I'm aiming to convert the following code: _1 = __dynamic_cast (obj_1(D), &_ZTI7Base, &_ZTI10Derived, 0); if (_1!

Re: COND_EXPR (?:) and its first operand in gimple

On Tue, Apr 9, 2024 at 11:02 PM Andrew Pinski (QUIC) wrote: > > While looking into PR 114666, I noticed that we don't verify COND_EXPR's > first operand. In most of my recent patches to match.pd, I was assuming that > it would be a boolean (or a type which would contain > [0,1]) but this PR show

COND_EXPR (?:) and its first operand in gimple

While looking into PR 114666, I noticed that we don't verify COND_EXPR's first operand. In most of my recent patches to match.pd, I was assuming that it would be a boolean (or a type which would contain [0,1]) but this PR shows we could end up with an 1-bit signed integer in there. We could fix m

Re: Question about constructing vector types in GIMPLE pass

I'm stucked with another problem that, I want to call > `__builtin_ia32_pmovmskb256` in the GIMPLE pass. But I found that this > function is defined in `config/i386/i386-builtins.h`. And when I try > to include this header file, the error will occur during the > compilation. If you k

Re: Question about constructing vector types in GIMPLE pass

); But when I print the `type_p`, it shows `vector(4) long int * {ref-all}`. So I'm confused if they are the same type or can be transferred to each other. And I'm stucked with another problem that, I want to call `__builtin_ia32_pmovmskb256` in the GIMPLE pass. But I found that this f

Re: Question about constructing vector types in GIMPLE pass

On Mon, 8 Apr 2024, Hanke Zhang via Gcc wrote: Hi, I've been working on strengthening auto-vectorization on intel CPUs recently. I tried to do it in the GIMPLE pass. And I noticed that some vector types in the GIMPLE code are confusing to me. The example code is here: _1 = MEM[(const __m2

Question about constructing vector types in GIMPLE pass

Hi, I've been working on strengthening auto-vectorization on intel CPUs recently. I tried to do it in the GIMPLE pass. And I noticed that some vector types in the GIMPLE code are confusing to me. The example code is here: _1 = MEM[(const __m256i_u * {ref-all})_2]; I wondered how I

Re: [gimple-ssa] result_decl and ssa_name

; wrote: > > Hi all, > > I do have a question regarding ssa_name and result_decl. > > For example on the following gimple function: > > int f () > { > int x; > int D.2747; > int _2; > >: > x_1 = 42; > _2 = x_1; > >: > : &

Re: [gimple-ssa] result_decl and ssa_name

do have a question regarding ssa_name and result_decl. >> >> For example on the following gimple function: >> >> int f () >> { >> int x; >> int D.2747; >> int _2; >> >>: >> x_1 = 42; >> _2 = x_1; >> >>: &

Re: [gimple-ssa] result_decl and ssa_name

On Fri, Apr 5, 2024 at 3:44 PM Pierrick Philippe wrote: > > On 05/04/2024 14:46, Richard Biener wrote: > > On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe > wrote: > > Hi all, > > I do have a question regarding ssa_name and result_decl. > > For example on the f

Re: [gimple-ssa] result_decl and ssa_name

On 05/04/2024 14:46, Richard Biener wrote: > On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe > wrote: >> Hi all, >> >> I do have a question regarding ssa_name and result_decl. >> >> For example on the following gimple function: >> >> int f

Re: [gimple-ssa] result_decl and ssa_name

On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe wrote: > > Hi all, > > I do have a question regarding ssa_name and result_decl. > > For example on the following gimple function: > > int f () > { > int x; > int D.2747; > int _2; > >: > x_

[gimple-ssa] result_decl and ssa_name

Hi all, I do have a question regarding ssa_name and result_decl. For example on the following gimple function: int f () {   int x;   int D.2747;   int _2;   :   x_1 = 42;   _2 = x_1;   : :   return _2; } On the above example, using the macro SSA_NAME_VAR() on _2 does not yield anything

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

ike YAML or JSON that other tools > can easily parse. And C++ code that emits equivalent GENERIC or GIMPLE, perhaps? Thanks, Florian

RE: New feature: -fdump-gimple-nodes (once more, with feeling)

t. Once the tree were available in JSON, then separate utilities to take that output and display it graphically would be straightforward. Okay then. I'll change the naming from "*gimple*" to "*generic*" as more accurate, and I'll generate JSON in addition to the othe

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

On Tue, Feb 13, 2024 at 01:46:11PM -0600, Robert Dubner wrote: ... > An example of a complete dump is available at > https://www.dubner.com/main.nodes.html. The C source code that generated > it is available at the end of > https://cobolworx.com/pages/dump-gimple-nodes.html > H

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

On Tue, 2024-02-13 at 23:40 -0800, Andi Kleen via Gcc wrote: > Robert Dubner writes: > > > There didn't seem to be any such functionality in GCC.  I found a > > routine > > in print-tree.cc which printed out a single node, but I needed to > > understand the entire tree of nodes for a function. >

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

nt end for GCC. He's > primarily been parsing the language. It's been my task to generate the > GENERIC/GIMPLE trees for the parsed code. We've been working at this for > a couple of years. We have reached the point where we want to start > submitting patches for the commu

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

Robert Dubner writes: > There didn't seem to be any such functionality in GCC. I found a routine > in print-tree.cc which printed out a single node, but I needed to > understand the entire tree of nodes for a function. FWIW the standard way to do this is to run the compiler in gdb with the .gdb

New feature: -fdump-gimple-nodes (once more, with feeling)

coding standards, so I have some idea of what's needed. But there is a gulf between theory and practice, and I am hoping for guidance. Jim Lowden and I have been developing a COBOL front end for GCC. He's primarily been parsing the language. It's been my task to generate the GENER

RE: New feature -fdump-gimple-nodes

, dammit. Bob Dubner. From: Robert Dubner Sent: Tuesday, February 13, 2024 14:01 To: 'GCC Mailing List' Subject: New feature -fdump-gimple-nodes I have not contributed to GCC before, so I am not sure how to go about it. So, I am letting you know what I want to do, so that I can get

New feature -fdump-gimple-nodes

. He's primarily been parsing the language. It's been my task to generate the GENERIC/GIMPLE trees for the parsed code. We've been working at this for a couple of years. We have reached the point where we want to start submitting patches for the community to evaluate. I figure

Re: Question on GIMPLE shifts

f(int x, int k) > > { > > int tmp = x >> k; > > return (tmp & 1) << 10; > > } > > > > If we would like to take a look into GIMPLE then we'll get: > > > > int f (int x, int k) > > { > >int tmp; > >

Re: Question on GIMPLE shifts

On Wed, Nov 1, 2023 at 3:56 AM Daniil Frolov wrote: > > Hi! > > When investigating bit shifts I got an incomprehensible moment with > the following example: > > int f(int x, int k) > { > int tmp = x >> k; > return (tmp & 1) << 10; > } >

Question on GIMPLE shifts

Hi! When investigating bit shifts I got an incomprehensible moment with the following example: int f(int x, int k) { int tmp = x >> k; return (tmp & 1) << 10; } If we would like to take a look into GIMPLE then we'll get: int f (int x, int k) { int tmp; int D.

Re: Question about gimple code during optimizing if-conversion

ement block has only if statement and no else statement, the source C code looks like this: int* foo; // assume this has been initialized int c = rand(), t = rand(), size = 1000; for (int i = 0; i < size; i++) { if (foo[i] & (1 << c)) foo[i] ^= (1 << t); } Part of its

Re: Question about gimple code during optimizing if-conversion

f statement and no else statement, the > source C code looks like this: > > int* foo; // assume this has been initialized > int c = rand(), t = rand(), size = 1000; > for (int i = 0; i < size; i++) { > if (foo[i] & (1 << c)) foo[i] ^= (1 << t); > } > &

Question about gimple code during optimizing if-conversion

been initialized int c = rand(), t = rand(), size = 1000; for (int i = 0; i < size; i++) { if (foo[i] & (1 << c)) foo[i] ^= (1 << t); } Part of its corresponding gimple is optimized like this before if-conversion: : # i_71 = PHI # ivtmp_9 = PHI _5 = (long unsig

Re: semantics of uninitialized values in GIMPLE

annoying, so I threw all away and wrote a new tool in C++. The new implementation now handles most of GIMPLE (but it still does not handle loops or function calls). I also have support for checking that the generated assembly has the same semantics as the optimized GIMPLE (only partial support fo

Re: semantics of uninitialized values in GIMPLE

new tool in C++. The new implementation now handles most of GIMPLE (but it still does not handle loops or function calls). I also have support for checking that the generated assembly has the same semantics as the optimized GIMPLE (only partial support for RISC-V for now). I plan to publish a write-up

Re: semantics of uninitialized values in GIMPLE

he test has an uninitialized bit > >>>> field > >>>> > >>>>unsigned char c6:1, c7:1, c8:1, c9:3, c10:1; > >>>> > >>>> which is written to as > >>>> > >>>>x.c6 = 0; > >>>>x.c7 = 0;

Re: semantics of uninitialized values in GIMPLE

initialized bits in BIT_AND_EXPR and BIT_OR_EXP, and propagating each bit according to * `0 & uninit` is an initialized `0` * `1 & uninit` is uninitialized * `0 | uninit` is uninitialized * `1 | uninit` is an initialized `1` Is that the correct GIMPLE semantics? I think the ab

Re: semantics of uninitialized values in GIMPLE

On Tue, Jul 11, 2023 at 12:56 AM Krister Walfridsson wrote: > > On Fri, 7 Jul 2023, Richard Biener wrote: > > >> I have implemented support for uninitialized memory in my translation > >> validator. But I am not sure how well this corresponds to the GIMPLE > >>

Re: semantics of uninitialized values in GIMPLE

On Fri, 7 Jul 2023, Richard Biener wrote: I have implemented support for uninitialized memory in my translation validator. But I am not sure how well this corresponds to the GIMPLE semantics, so I have some questions... My implementation tracks uninitialized bits. Use of uninitialized bits is

Re: semantics of uninitialized values in GIMPLE

On Fri, Jul 7, 2023 at 1:23 AM Krister Walfridsson via Gcc wrote: > > I have implemented support for uninitialized memory in my translation > validator. But I am not sure how well this corresponds to the GIMPLE > semantics, so I have some questions... > > My implementation tr

semantics of uninitialized values in GIMPLE

I have implemented support for uninitialized memory in my translation validator. But I am not sure how well this corresponds to the GIMPLE semantics, so I have some questions... My implementation tracks uninitialized bits. Use of uninitialized bits is in general treated as UB (for example, `x

Re: types in GIMPLE IR

On Thu, Jun 29, 2023 at 12:10 PM Krister Walfridsson via Gcc wrote: > > On Thu, 29 Jun 2023, Richard Biener wrote: > > > IIRC we have some simplification rules that turn bit operations into > > arithmetics. Arithmetic is allowed if it keeps the values inside > > [-1,0] for signed bools or [0, 1]

Re: types in GIMPLE IR

On Thu, 29 Jun 2023, Richard Biener wrote: IIRC we have some simplification rules that turn bit operations into arithmetics. Arithmetic is allowed if it keeps the values inside [-1,0] for signed bools or [0, 1] for unsigned bools. I have now verified that all cases seems to be just one operat

Re: types in GIMPLE IR

On Thu, Jun 29, 2023 at 2:06 PM Krister Walfridsson wrote: > > On Thu, 29 Jun 2023, Richard Biener wrote: > > > The thing with signed bools is that the two relevant values are -1 (true) > > and 0 (false), those are used for vector bool components where we also > > need them to be of wider type (32

Re: types in GIMPLE IR

Hello, On Thu, 29 Jun 2023, Krister Walfridsson wrote: > > The thing with signed bools is that the two relevant values are -1 (true) > > and 0 (false), those are used for vector bool components where we also > > need them to be of wider type (32bits in this case). > > My main confusion comes fro

Re: types in GIMPLE IR

On Thu, 29 Jun 2023, Richard Biener wrote: The thing with signed bools is that the two relevant values are -1 (true) and 0 (false), those are used for vector bool components where we also need them to be of wider type (32bits in this case). My main confusion comes from seeing IR doing arithmet

Re: types in GIMPLE IR

; > in expressions, such as: > > > >_2; > > _Bool _3; > > _Bool _4; > > ... > > _4 = _2 ^ _3; > > > > and similarly mixing _Bool and enum > > > > enum E:bool { E0, E1 }; > > > > in one operation. > > > &g

Re: types in GIMPLE IR

gt; > and similarly mixing _Bool and enum > > enum E:bool { E0, E1 }; > > in one operation. > > I had expected this to be invalid... What are the type safety rules in the > GIMPLE IR? Type safety in gimple is defined in terms of type compatiblity, with _many_ excepti

types in GIMPLE IR

I have some random questions concerning types in the GIMPLE IR that I would appreciate some clarification on. Type safety --- Some transformations treat 1-bit types as a synonym of _Bool and mix the types in expressions, such as: _2; _Bool _3; _Bool _4; ... _4 = _2 ^ _3

Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

m doing is basically looking at each gimple statement if the lhs has a > given attribute for the purpose of the analysis I'm trying to perform. > To precise, I'm plugged into the analyzer, so an out-of-tree plugin. > > But in the example above, the definition of x is not rea

Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

On 27/06/2023 11:42, Richard Biener wrote: On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe wrote: Hi everyone, I'm trying to get the gimple * associated to the definition of a given var_decl. Basically, I am iterating over the locals of a function (through the local_decls member)

Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe wrote: > > Hi everyone, > > I'm trying to get the gimple * associated to the definition of a given > var_decl. > Basically, I am iterating over the locals of a function (through the > local_decls member) and I need to

[gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

Hi everyone, I'm trying to get the gimple * associated to the definition of a given var_decl. Basically, I am iterating over the locals of a function (through the local_decls member) and I need to be able to get the gimple * of its definition within the function's gimple_seq. D

Re: Different outputs in Gimple pass dump generated by two different architectures

On Fri, Nov 11, 2022 at 8:39 AM Andrew Pinski wrote: > > On Fri, Nov 11, 2022 at 12:57 AM Marc Glisse via Gcc wrote: > > > > On Thu, 10 Nov 2022, Kevin Lee wrote: > > > What would be causing the difference? Is this intended? Link > > > for details. Thank you! >

Re: Different outputs in Gimple pass dump generated by two different architectures

On Fri, Nov 11, 2022 at 12:57 AM Marc Glisse via Gcc wrote: > > On Thu, 10 Nov 2022, Kevin Lee wrote: > > > While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that > > x86-64 and risc-v has a different output for the gimple pass since > > r12-4790-g

Re: Different outputs in Gimple pass dump generated by two different architectures

On Thu, 10 Nov 2022, Kevin Lee wrote: While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that x86-64 and risc-v has a different output for the gimple pass since r12-4790-g4b3a325f07acebf4 <https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4b3a325f07acebf4>. Probably

Different outputs in Gimple pass dump generated by two different architectures

Hello GCC, While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that x86-64 and risc-v has a different output for the gimple pass since r12-4790-g4b3a325f07acebf4 <https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4b3a325f07acebf4>. What would be causing the difference? I

Re: GIMPLE undefined behavior

ow often this > happens... Can you report a single case as kind-of meta-bug for this particular issue? That would be nice. > > >> Calling f(-3, 0x75181005) makes slsr_9 overflow in the optimized code, > >> even though the original did not overflow. My understanding is that signed >

Re: GIMPLE undefined behavior

ad this as I should not report these as bugs for now. But I'll probably keep this as UB in my tool to get an idea of how often this happens... Calling f(-3, 0x75181005) makes slsr_9 overflow in the optimized code, even though the original did not overflow. My understanding is that signed o

Re: GIMPLE undefined behavior

On Thu, Sep 1, 2022 at 1:57 AM Krister Walfridsson via Gcc wrote: > > I'm implementing a tool for translation validation (similar to Alive2 for > LLVM). The tool uses an SMT solver to verify for each GIMPLE pass that the > output IR is a refinement of the input IR: >

GIMPLE undefined behavior

I'm implementing a tool for translation validation (similar to Alive2 for LLVM). The tool uses an SMT solver to verify for each GIMPLE pass that the output IR is a refinement of the input IR: * That each compiled function returns an identical result before/after the pass (for input

Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc

:= a != 0; > 3:7:b_ := b != 0; > 3:8:c_ := c != 0; > -:9: > 3*: 10:if a_ && (b_ || c_) { > condition outcomes covered 2/2 > condition outcomes covered 1/2 > condition 0 not covered (true) > c

Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc

3:    6:    a_ := a != 0; >     3:    7:    b_ := b != 0; >     3:    8:    c_ := c != 0; >     -:    9: >    3*:   10:    if a_ && (b_ || c_) { > condition outcomes covered 2/2 > condition outcomes covered 1/2 > condition  0 not covered (tr

gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc

urn 1; -: 12:} else { 2: 13:return 0; -: 14:} -: 15:} So I dumped the gimple gcc -fdump-tree-gimple abc.go: int main.fn (int a, int b, int c) { int D.2725; int $ret0; $ret0 = 0; { bool a_; bool b_; bool

Ferching Rtl instruction corressponding to Gimple Call instruction

Hello, I want to collect complete rtl instruction corresponding to below gimple call - "__builtin_temp" I have gimple instructions of form - slli_31 = _2 << 8; srli_32 = slli_31 >> 8; add_33 = srli_32 + 15; _20 = __builtin_temp (instrn_buffer.36_1, 1, add_33); For tha

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

awar via Gcc > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > I want to know whether it is cor

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

ote: > > > > > > > > > > > > > > > > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc > > > > > > > > wrote: > > > > > > > > > > > > &g

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

> > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > I want to know whether it is correct to add left shift > > > > > > > > instruction to > > > > >

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

> > > > > > > > > > > > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc > > > > > > wrote: > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I want to

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

t; > > > > Hello, > > > > > > > > > > > > I want to know whether it is correct to add left shift instruction > > > > > > to > > > > > > a constant expression statement like "_3 + 4"? > > &g

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

ft instruction to > > > > > a constant expression statement like "_3 + 4"? > > > > > > > > > > I am trying to add a left shift instruction in between below GIMPLE > > > > > instructions - > > > > > > >

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

Gcc > > > wrote: > > > > > > > > Hello, > > > > > > > > I want to know whether it is correct to add left shift instruction to > > > > a constant expression statement like "_3 + 4"? > > > > > > > &g

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

know whether it is correct to add left shift instruction to > > > a constant expression statement like "_3 + 4"? > > > > > > I am trying to add a left shift instruction in between below GIMPLE > > > instructions - > > > > > >: > >

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

"_3 + 4"? > > > > I am trying to add a left shift instruction in between below GIMPLE > > instructions - > > > >: > > instrn_buffer.0_1 = instrn_buffer; > > _2 = tree.cnt; > > _3 = (int) _2; > > _4 = _3 + 4; > &

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc wrote: > > Hello, > > I want to know whether it is correct to add left shift instruction to > a constant expression statement like "_3 + 4"? > > I am trying to add a left shift instruction in betw

Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

Hello, I want to know whether it is correct to add left shift instruction to a constant expression statement like "_3 + 4"? I am trying to add a left shift instruction in between below GIMPLE instructions - : instrn_buffer.0_1 = instrn_buffer; _2 = tree.cnt; _3 = (int) _2;

Re: Query regarding generating NOTE instruction at GIMPLE level

On Sun, Feb 6, 2022 at 8:42 PM Shubham Narlawar via Gcc wrote: > > Hello, > > Is it possible to generate a NOTE instruction at GIMPLE level? > > My use case scenario is as below - > I want to create a note for __builtin_xyz(_x) such that there is a > placeholder just bef

Query regarding generating NOTE instruction at GIMPLE level

Hello, Is it possible to generate a NOTE instruction at GIMPLE level? My use case scenario is as below - I want to create a note for __builtin_xyz(_x) such that there is a placeholder just before function call and in RTL pass, I want to modify/assign register number at this placeholder location

Re: Updating phi nodes on deleting gimple statement

On Thu, 16 Dec, 2021, 6:28 pm Richard Biener, wrote: > On December 16, 2021 7:33:37 AM GMT+01:00, Shubham Narlawar via Gcc < > gcc@gcc.gnu.org> wrote: > >Hello, > > > > > >I have a PHI node that defines a variable that is used in 1 statement. I > >then delete the statement. I think I need to upda

Re: Updating phi nodes on deleting gimple statement

On December 16, 2021 7:33:37 AM GMT+01:00, Shubham Narlawar via Gcc wrote: >Hello, > > >I have a PHI node that defines a variable that is used in 1 statement. I >then delete the statement. I think I need to update the PHI node to no >longer reference that variable. I looked through some code and

Updating phi nodes on deleting gimple statement

Hello, I have a PHI node that defines a variable that is used in 1 statement. I then delete the statement. I think I need to update the PHI node to no longer reference that variable. I looked through some code and I don't see a way to just remove an element from a PHI node and I see in the file o

Re: Extracting function name from the gimple call statement

On Mon, Oct 11, 2021 at 2:51 AM David Malcolm wrote: > > On Sun, 2021-10-10 at 23:04 +0530, Shubham Narlawar via Gcc wrote: > > Hello, > > > > Is there a direct way to print the name of the function call in gimple > > call > > statement? > > > >

Re: Extracting function name from the gimple call statement

On Sun, 2021-10-10 at 23:04 +0530, Shubham Narlawar via Gcc wrote: > Hello, > > Is there a direct way to print the name of the function call in gimple > call > statement? > > For example - > > void bar() { > a = foo();    //gimple* stmt > } > > I wa

Extracting function name from the gimple call statement

Hello, Is there a direct way to print the name of the function call in gimple call statement? For example - void bar() { a = foo();//gimple* stmt } I want to print "foo" from the above gimple*. I traced debug_gimple_stmt(gimple*) but it seems complex to just print "foo

Re: What is this GIMPLE?

On Thu, Aug 26, 2021 at 9:57 AM Gary Oblock wrote: > > Richard, > > It sure looked a label but I had code that would bail out on > a label before it ever got where I was seeing a problem. > > I finally printed out the gimple code and it was a GIMPLE_DEBUG! > When I bail

Re: What is this GIMPLE?

Richard, It sure looked a label but I had code that would bail out on a label before it ever got where I was seeing a problem. I finally printed out the gimple code and it was a GIMPLE_DEBUG! When I bailed out on debugs my pass worked again. Of course expanding debugging info failed in cfgexpand

Re: What is this GIMPLE?

On Wed, Aug 25, 2021 at 7:30 AM Gary Oblock via Gcc wrote: > > I print out a bit of GIMPLE for a program and it looks like this: > >[local count: 13634385]: > # a_1 = PHI > # n_11 = PHI > loop: > # DEBUG n => n_11 > # DEBUG a => a_1 > _2 = (lon

What is this GIMPLE?

I print out a bit of GIMPLE for a program and it looks like this: [local count: 13634385]: # a_1 = PHI # n_11 = PHI loop: # DEBUG n => n_11 # DEBUG a => a_1 _2 = (long unsigned int) a_1; _3 = _2 & 7; _347 = _3 != 0; That bit that says "loop:" isn't

Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)

> Good hint. I added hash based on object file name (I don't want to handle > proper string escaping) and -frandom-seed. > > What do you think about the patch? Sorry for taking so long - I remember I was sending reply earlier but it seems I only wrote it and never sent. > Thanks, > Martin > From

Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)

hat once for each frontend). When building a GCC package, we intentionally re-link them with all FEs. If it is to speedup dev (re-)builds then dragging in more files will make it build longer since for example insn-recog.c may be unchanged but gimple-match.c not. Yes, the original motivation was

Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)

On 8/16/21 3:58 PM, Martin Liška wrote: PING^2 @Honza: Can you please review the change? I've tested the patch and apparently it's not enough for {gimple,generic}-match.o not clashing in symbol names. Apparently there are more IPA clones that collide. Leaving that for now. Martin

Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)

PING^2 @Honza: Can you please review the change? Martin On 6/23/21 3:53 PM, Martin Liška wrote: On 5/21/21 10:29 AM, Martin Liška wrote: On 5/20/21 5:55 PM, Jan Hubicka wrote: Quick solution is to also modify partitioner to use the local symbol names when doing incremental linking (those mix

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On Wed, Jul 14, 2021 at 09:39:42AM +0200, Richard Biener via Gcc-help wrote: > On Wed, Jul 14, 2021 at 9:00 AM Hongtao Liu via Gcc-patches > wrote: > > > > On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz wrote: > > > > > > On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote: >

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On Wed, Jul 14, 2021 at 10:56 AM Hongtao Liu wrote: > > On Wed, Jul 14, 2021 at 4:17 PM Richard Biener > wrote: > > > > On Wed, Jul 14, 2021 at 10:11 AM Hongtao Liu wrote: > > > > > > On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote: > > > > > > > > On Wednesday, 14 July 2021 09:39:42 CEST

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On 14/07/2021 09:49, Matthias Kretz wrote: > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote: >> -ffast-math decomposes to quite some flag_* and those generally are not >> reflected into the IL but can be different per function (and then >> prevent inlining). > > Is there any chance

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On Wed, Jul 14, 2021 at 4:17 PM Richard Biener wrote: > > On Wed, Jul 14, 2021 at 10:11 AM Hongtao Liu wrote: > > > > On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote: > > > > > > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote: > > > > -ffast-math decomposes to quite some flag

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On Wed, Jul 14, 2021 at 10:11 AM Hongtao Liu wrote: > > On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote: > > > > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote: > > > -ffast-math decomposes to quite some flag_* and those generally are not > > > reflected into the IL but can be

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On Wed, Jul 14, 2021 at 9:49 AM Matthias Kretz wrote: > > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote: > > -ffast-math decomposes to quite some flag_* and those generally are not > > reflected into the IL but can be different per function (and then > > prevent inlining). > > Is t

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote: > > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote: > > -ffast-math decomposes to quite some flag_* and those generally are not > > reflected into the IL but can be different per function (and then > > prevent inlining). > > Is t

  1   2   3   4   5   6   7   8   9   10   >