Re: [1-800-GIT-HELP] Backporting a series of commits into a combined commit?

On Mon, Jun 1, 2020 at 2:17 PM Thomas Koenig via Fortran wrote: > > Hi Martin, > > > For now, I would recommend doing 1:1 backports. Otherwise, you'll need > > to merge > > all ChangeLog entries in a format the server hook accepts. That can > > require some > > work. > > If the first commit caused

Re: Question about comparing function function decls

On Thu, Jun 4, 2020 at 10:24 PM Gary Oblock via Gcc wrote: > > > > > > I'm trying to determine during LTO optimization (with one partition) > whether of not a function call is to a function in the partition. > > Here is the routine I've written. Note, I'm willing t

Re: gcc math functions for OpenMP vectoization

On June 5, 2020 7:58:20 PM GMT+02:00, Toon Moene wrote: >On 6/5/20 6:10 PM, Tobias Burnus wrote: > >> On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote: > >>> It is glibc that provides them, not GCC. >>> See >>> >https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0

Re: Inquire a potential bug when printing out GIMPLE ASAN statements

On Tue, Jun 9, 2020 at 3:38 AM Shuai Wang via Gcc wrote: > > Hello! > > I am writing to report a potential bug I encountered when playing with the > GIMPLE IR. I enabled the ASan and would like to print out all ASAN_MARK > statements for the following simple code: > > int main(int argc ,char **ar

Re: Seeking clarification and way forward on limited scope variables.

On Tue, Jun 9, 2020 at 8:00 AM Tomar, Sourabh Singh wrote: > > [AMD Official Use Only - Internal Distribution Only] > > Hello Everyone, > > I need to have your thoughts on this. > > Consider the following test case -- > --- > 1int main(int Argc, char **

Re: Push to my private branches is disallowed

On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool wrote: >Hi! > >$ git push -n fsf >To git+ssh://gcc.gnu.org/git/gcc.git > + 1db88c6...71e5e35 cc0 -> refs/users/segher/heads/cc0 (forced update) > >$ git push fsf >Counting objects: 664, done. >Delta compression using up to 64 threads. >Com

Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional

On June 15, 2020 6:31:38 PM GMT+02:00, Shuai Wang via Gcc wrote: >Hello, > >Suppose given the following SSA statement generated by the `sanopt` >pass: > > _17 = (signed char *) _16; > _18 = *_17; > >I am using the following code to identify that _17 depends on _16: > >// def_stmt refers to _1

Re: Push to my private branches is disallowed

On June 15, 2020 7:19:13 PM GMT+02:00, Joseph Myers wrote: >On Mon, 15 Jun 2020, Segher Boessenkool wrote: > >> It should never send email for things that are on master (or any >release >> branch) already. > >https://github.com/AdaCore/git-hooks/issues/9 > >https://github.com/AdaCore/git-hooks/pu

Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional

6 in the IR code are >SSA >variables. They are initialized for once and used once. Could you >please >shed some light on where "non-ssa name" comes in this scenario, and how >exactly can I get _17 = (signed char *) _16 printed out? Thank you >very >much. > >B

Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional

the _17 in my sample code), how can >> I find its def statement? Thank you very much. >> >> Shuai >> >> On Tue, Jun 16, 2020 at 3:19 AM Richard Biener >> wrote: >>> >>> On June 15, 2020 6:58:27 PM GMT+02:00, Shuai Wang >>> wrote:

Re: Re-optimize instrumented GIMPLE code

On Wed, Jun 17, 2020 at 4:11 AM Shuai Wang via Gcc wrote: > > Hello, > > Suppose I have changed certain if condition in the GIMPLE code (generated > by the `sanopt` pass) into the following format: > > if (0 == 1) > { > > } > > Then, in order to completely remove this unnecessary if condit

Re: Exception at "need_ssa_update_p" during GIMPLE instrumentation

On June 21, 2020 11:38:49 AM GMT+02:00, Shuai Wang via Gcc wrote: >OK, I think I know how to solve it. Just return TODO_update_ssa >. If you dump with -vops you'll likely see that virtual operands got out of sync. You can either manually copy

Re: GIMPLE problem

On Wed, Jun 24, 2020 at 1:36 AM Gary Oblock via Gcc wrote: > > I'm somehow misusing GIMPLE (probably in multiple ways) and I need > some help in straightening out this little mess I've made. > > I'm trying to do the following: > > In an attempt at structure reorganization (instance interleaving) a

Re: GIMPLE problem

On Wed, Jun 24, 2020 at 9:05 PM Gary Oblock via Gcc wrote: > > Richard, > > First off I did suspect INDIRECT_REF wasn't supported, thanks for > confirming that. > > I tried what you said in the original code before I posted > but I suspect how I went at it is the problem. I'm probably > doing some

Re: Hoisting DFmode loads out of loops..

On June 26, 2020 3:24:24 AM GMT+02:00, Alan Lehotsky wrote: >On Jun 25, 2020, at 6:37 PM, Jeff Law >mailto:l...@redhat.com>> wrote: > >On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote: >I’m working on a GCC 8.3 port to a load/store architecture with a >32-bit data-path between registers and

Re: Support for named address spaces in C++

On Fri, Jun 26, 2020 at 9:12 AM Georg-Johann Lay wrote: > > Andrew Pinski via Gcc schrieb: > > On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc > > wrote: > >> Hi all, > >> > >> I’ve added a named address space to our backend and I noticed that it is > >> only support in C. > >> Has anyone

Re: Passing an string argument to a GIMPLE call

On June 27, 2020 6:21:12 AM GMT+02:00, Shuai Wang via Gcc wrote: >Hello, > >I am writing the following statement to make a GIMPLE call: > > tree function_fn_type = build_function_type_list(void_type_node, >void_type_node, integer_type_node, NULL_TREE); > tree sancov_fndecl = build_fn_de

Re: Passing an string argument to a GIMPLE call

>stmt has a location_t (although this isn't always set for every stmt). > >Given a location_t, you can use LOCATION_FILE (loc) to get the source >file (and various other macros and accessors, see input.h) > >Hope this is helpful >Dave > >> Best, >> Shuai &g

Re: RFC noipa sizeof function for record relayout at link time

On Mon, Jun 29, 2020 at 11:56 AM Erick Ochoa wrote: > > Hello, > > I have been working on link time optimization for C that may change the > size of structs (at link time). We are close to sharing the results we > have so far, but there are a couple of missing pieces left to work on: > > Implement

Re: RFC noipa sizeof function for record relayout at link time

On Mon, Jun 29, 2020 at 1:05 PM Richard Biener wrote: > > On Mon, Jun 29, 2020 at 11:56 AM Erick Ochoa > wrote: > > > > Hello, > > > > I have been working on link time optimization for C that may change the > > size of structs (at link time). We are clos

Re: An problematic interaction between a call created by gimple_build_call and inlining

On Wed, Jul 1, 2020 at 7:49 AM Gary Oblock via Gcc wrote: > > I'm trying to generate calls to "free" on the fly at ipa time. > > I've tried several things (given below) but they both fail > in expand_call_inline in tree-inline.c on this gcc_checking_assert: > > cg_edge = id->dst_node->get_edge (

Re: Questions regarding control flow during IPA passes

On Fri, Jul 3, 2020 at 6:04 AM Gary Oblock via Gcc wrote: > > At IPA time I'm creating GIMPLE statements. I've noticed during dumps > that gotos and labels don't seem to exist. In fact when I tried > introducing them, at least the gotos, failed. I assume that at this > point in compilation GCC re

Re: Local optimization options

On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" wrote: >Hi, > >in Fortran, it would sometimes be useful to have a different >optimization >depending on whether we generate inlined code for intrinsics (where we >know when it is OK to „go wild“) or user code, where we need to >adhere (for ex

Re: Local optimization options

On July 5, 2020 12:37:58 PM GMT+02:00, "Thomas König" wrote: > >> Am 04.07.2020 um 19:11 schrieb Richard Biener >: >> >> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" > wrote: >>> >>> What could be a preferred way to

Re: Local optimization options

On Sun, Jul 5, 2020 at 4:37 PM Marc Glisse wrote: > > On Sun, 5 Jul 2020, Thomas König wrote: > > > > >> Am 04.07.2020 um 19:11 schrieb Richard Biener : > >> > >> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" > >> wrote: >

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

On July 9, 2020 3:43:19 PM GMT+02:00, David Edelsohn via Gcc wrote: >On Thu, Jul 9, 2020 at 9:07 AM Matthias Klose wrote: >> >> On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote: >> > On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose >wrote: >> >> >> >> https://gcc.gnu.org/gcc-8/criteria.html lists t

Re: New x86-64 micro-architecture levels

On Fri, Jul 10, 2020 at 11:45 PM H.J. Lu via Gcc wrote: > > On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer wrote: > > > > Most Linux distributions still compile against the original x86-64 > > baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel > > EM64T compatibility). > >

Re: New x86-64 micro-architecture levels

On Mon, Jul 13, 2020 at 9:40 AM Florian Weimer wrote: > > * Richard Biener: > > >> Looks good. I like it. > > > > Likewise. Btw, did you check that VIA family chips slot into Level A > > at least? > > Those seem to lack SSE4.2, so they land in the b

Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'

On Tue, Jul 14, 2020 at 7:24 AM Andreas Schwab wrote: > > On Jul 14 2020, Maciej W. Rozycki wrote: > > > Arguably this might probably be called a deficiency in libgcc, however > > the objects are built with `-fexceptions -fnon-call-exceptions' > > I consider that broken. It doesn't make any sens

Re: Understand pointer deferences in GIMPLE

On Tue, Jul 14, 2020 at 9:17 AM Shuai Wang via Gcc wrote: > > Hello, > > I am trying to traverse the GIMPlE statements and identify all pointer > differences (i.e., memory load and store). For instance, something like: > > **_4* = 0; >... > _108 = (signed char *) _107; > _109 = **_108*;

Re: GCC Plugin to insert new expressions/statements in the code

On Tue, Jul 14, 2020 at 11:23 PM Masoud Gholami wrote: > > Hi, > > I am writing a plugin that uses the PLUGIN_PRAGMAS event to register a > custom pragma that is expected to be before a function call as follows: > > int main() { > > char *filename = “path/to/file”; > #pragma inje

Re: Crash at gimple_code(gimple* )

On Wed, Jul 15, 2020 at 9:30 AM Shuai Wang via Gcc wrote: > > Hello, > > I am using the following code to iterate different gimple statements: > > ... > gimple* stmt = gsi_stmt(gsi); > if (gimple_assign_load_p(stmt)) { > tree rhs = gimple_assign_rhs1 (stmt); > if (!rhs) return; >

Re: Default defs question

On July 16, 2020 7:09:21 AM GMT+02:00, Gary Oblock via Gcc wrote: >Regarding the other question I asked today could somebody explain to >me what the default_defs are all about. Default defs are SSA names without an explicit defining statement for example those representing values at function e

Re: New x86-64 micro-architecture levels

On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc wrote: > > * Dongsheng Song: > > > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I > > recommend using isa tags by year (e.g. x64_2010, x64_2014) like the > > python's platform tags (e.g. manylinux2010, manylinux2014).

Re: Three issues

On Wed, Jul 22, 2020 at 12:51 AM Gary Oblock via Gcc wrote: > > Some background: > > This is in the dreaded structure reorganization optimization that I'm > working on. It's running at LTRANS time with '-flto-partition=one'. > > My issues in order of importance are: > > 1) In gimple-ssa.h, the equ

Re: New x86-64 micro-architecture levels

On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote: > > * Richard Biener: > > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc > > wrote: > >> > >> * Dongsheng Song: > >> > >> > I fully agree these names (100/101, A/B/C/D)

Re: Three issues

node) > { > struct function *func = DECL_STRUCT_FUNCTION ( node->decl); > push_cfun ( func); > DEFAULT_DEFS ( func)->traverse_noresize < tree *, wf_func> ( NULL); > pop_cfun (); > } > fprintf( stderr, "Wolf Fence: Didn't find wolf!

Re: Problems with changing the type of an ssa name

On July 25, 2020 7:30:48 AM GMT+02:00, Gary Oblock via Gcc wrote: >If you've followed what I've been up to via my questions >on the mailing list, I finally traced my latest big problem >back to to my own code. In a nut shell here is what >I'm doing. > >I'm creating a new type exaactly like this:

Re: Problems with changing the type of an ssa name

at >are default defs. Well, just changing the SSA names doesn't make it less ramifications. You have to know what you are doing. So - what's the reason you need to change those SSA name types? Richard. >Gary >________ >From: Richard Biener >S

Re: TImode for BITS_PER_WORD=32 targets

On Fri, Jul 24, 2020 at 5:38 PM Andrew Stubbs wrote: > > Hi all, > > I want amdgcn to be able to support int128 types, partly because they > might come up in code offloaded from x86_64 code, and partly because > libgomp now requires at least some support (amdgcn builds have been > failing since ye

Re: Problems with changing the type of an ssa name

k them: FOR_EACH_IMM_USE_STMT (...) FOR_EACH_IMM_USE_ON_STMT (..) ... also the SSA definition statement after your transform cannot be the same so you have to create another stmt anyway, no? Richard. > Thanks, > > Gary > > From: Ri

Re: Tar version being used

On Mon, Jul 27, 2020 at 12:59 PM CHIGOT, CLEMENT via Gcc wrote: > > Hi everyone, > > I'm wondering if someone knows which tar version / configuration was being > used when creating gcc-10.2.0 tarballs ? > > I'm getting some directory checksum errors while trying to unpack it with the > AIX tar (

Re: LTO Dead Field Elimination

On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa wrote: > > This patchset brings back struct reorg to GCC. > > We’ve been working on improving cache utilization recently and would > like to share our current implementation to receive some feedback on it. > > Essentially, we’ve implemented the following

Re: LTO Dead Field Elimination

On Mon, Jul 27, 2020 at 2:59 PM Christoph Müllner wrote: > > Hi Richard, > > On 7/27/20 2:36 PM, Richard Biener wrote: > > On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa > > wrote: > >> > >> This patchset brings back struct reorg to GCC. > >> >

Re: Gcc Digest, Vol 5, Issue 52

On Tue, Jul 28, 2020 at 4:36 AM Gary Oblock via Gcc wrote: > > Almost all of the makes sense to. > > I'm not sure what a conditionally initialized pointer is. { void *p; if (condition) p = ...; if (other condition) ... use p; will end up with a PHI node after the conditional init

Re: Gcc Digest, Vol 5, Issue 52

sformations. It's not intended as > catch-all for things I don't understand rather it's an > aid to find possible new cases. However, there are > legitimate things at this point in time during development > of this optimization that I need to spot things this way. Later, &

Re: Gcc Digest, Vol 5, Issue 52

; > I hope that's sufficient to satisfy your curiosity because the only other > large transformation currently coded is that for the malloc which would > take me quite a while to put together an example of. Note, these are > shown in the HL design doc which I sent you. Though like bat

Re: Define __attribute__((no_instrument_function)) but still got instrumented

On Fri, Aug 7, 2020 at 8:35 AM Shuai Wang via Gcc wrote: > > Hello! > > I am working on a ARM GCC plugin which instruments each GIMPLE function > with some new function calls. > > Currently I want to skip certain functions by adding the > no_instrument_function attribute. However, I do see that in

Re: Has FSF stopped processing copyright paperwork?

On Fri, Aug 7, 2020 at 3:14 PM H.J. Lu via Gcc wrote: > > On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote: > > > > On 2/5/20 11:49 pm, H.J. Lu wrote: > > > On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils > > > wrote: > > >> > > >> On 19/3/20 12:02 pm, H.J. Lu wrote: > > >>> Kaylee, i

Re: Silly question about pass numbers

On August 13, 2020 2:57:04 AM GMT+02:00, Gary Oblock via Gcc wrote: >Segher, > >If this was on the mainline and not in the middle of a >nontrivial optimization effort I would have filed a bug report >and not asked a silly question. 😉 > >I'm at a total lost as to how I could have caused the pass >

Re: RFC: -fno-share-inlines

On Mon, Aug 10, 2020 at 9:36 AM Allan Sandfeld Jensen wrote: > > Following the previous discussion, this is a proposal for a patch that adds > the flag -fno-share-inlines that can be used when compiling singular source > files with a different set of flags than the rest of the project. > > It basi

Re: Problem cropping up in Value Range Propogation

On Tue, Aug 11, 2020 at 6:15 AM Gary Oblock via Gcc wrote: > > I'm trying to debug a problem cropping up in value range propagation. > Ironically I probably own an original copy 1995 copy of the paper it's > based on but that's not going to be much help since I'm lost in the > weeds. It's running

Re: GCC Plugins and global_options

On Thu, Aug 13, 2020 at 10:39 AM Jakub Jelinek via Gcc wrote: > > Hi! > > Any time somebody adds or removes an option in some *.opt file (which e.g. > on the 10 branch after branching off 11 happened 5 times already), many > offsets in global_options variable change. It is true we don't guarantee

Re: Question about IPA-PTA and build_alias

On Mon, Aug 17, 2020 at 3:22 PM Erick Ochoa wrote: > > Hello, > > I'm looking to understand better the points-to analysis (IPA-PTA) and > the alias analysis (build_alias). > > How is the information produced by IPA-PTA consumed? > > Are alias sets in build_alias computed by the intersections of th

Re: Peephole optimisation: isWhitespace()

On Mon, Aug 17, 2020 at 7:09 PM Stefan Kanthak wrote: > > "Allan Sandfeld Jensen" wrote: > > > On Freitag, 14. August 2020 18:43:12 CEST Stefan Kanthak wrote: > >> Hi @ll, > >> > >> in his ACM queue article , > >> Matt Godbolt used the function > >> >

Re: Question about Gimple Variables named D.[0-9]*

On Thu, Aug 20, 2020 at 11:51 AM Erick Ochoa wrote: > > Hello, > > I am looking at the dump for the build_alias pass. I see a lot of > variables with the naming convention D.[0-9]* in the points-to sets > being printed. > > When I compile with > > -fdump-tree-all-all > > I can see that the suffix

Re: Peephole optimisation: isWhitespace()

On Mon, Aug 24, 2020 at 1:22 PM Stefan Kanthak wrote: > > "Richard Biener" wrote: > > > On Mon, Aug 17, 2020 at 7:09 PM Stefan Kanthak > > wrote: > >> > >> "Allan Sandfeld Jensen" wrote: > >> > >> >

Re: Do all global structure variables escape in IPA-PTA?

On August 25, 2020 3:09:13 PM GMT+02:00, Erick Ochoa wrote: >Hi, > >I'm trying to understand how the escape analysis in IPA-PTA works. I >was >testing a hypothesis where if a structure contains an array of >characters and this array of characters is passed to fopen, the >structure and all subf

Re: Question about IPA-PTA and build_alias

On August 24, 2020 10:00:44 AM GMT+02:00, Erick Ochoa wrote: > > >On 24/08/2020 09:40, Richard Biener wrote: >> On Mon, Aug 17, 2020 at 3:22 PM Erick Ochoa >> wrote: >>> >>> Hello, >>> >>> I'm looking to understand better the points-

Re: Do all global structure variables escape in IPA-PTA?

On August 25, 2020 6:36:19 PM GMT+02:00, Erick Ochoa wrote: > > >On 25/08/2020 17:19, Erick Ochoa wrote: >> >> >> On 25/08/2020 17:10, Richard Biener wrote: >>> On August 25, 2020 3:09:13 PM GMT+02:00, Erick Ochoa >>> wrote: >>>> Hi, &

Re: Do all global structure variables escape in IPA-PTA?

On Wed, Aug 26, 2020 at 11:45 AM Erick Ochoa wrote: > > > > On 26/08/2020 10:36, Erick Ochoa wrote: > > > > > > On 25/08/2020 22:03, Richard Biener wrote: > >> On August 25, 2020 6:36:19 PM GMT+02:00, Erick Ochoa > >> wrote: > >

Re: LTO slows down calculix by more than 10% on aarch64

On Wed, Aug 26, 2020 at 12:34 PM Prathamesh Kulkarni via Gcc wrote: > > Hi, > We're seeing a consistent regression >10% on calculix with -O2 -flto vs -O2 > on aarch64 in our validation CI. I tried to investigate this issue a > bit, and it seems the regression comes from inlining of orthonl into >

Re: Questions regarding update_stmt and release_ssa_name_fn.

On Wed, Aug 26, 2020 at 11:32 PM Gary Oblock via Gcc wrote: > > I'm having some major grief with a few related things that I'm try to > do. The mostly revolve around trying to change the type of an SSA name > (which I've given up in favor of creating new SSA names and replacing > the ones I wanted

Re: Questions regarding update_stmt and release_ssa_name_fn.

A operand of that stmt. Richard. >Thanks, > >Gary > >From: Richard Biener >Sent: Thursday, August 27, 2020 2:04 AM >To: Gary Oblock >Cc: gcc@gcc.gnu.org >Subject: Re: Questions regarding update_stmt and release_ssa_name_fn. > >[EXTER

Re: Questions regarding update_stmt and release_ssa_name_fn.

type_t * min_x; > int i; > struct type_t * data; > >[local count: 10737416]: > data_10 = malloc (16); > goto ; [100.00%] > >[local count: 1063004409]: > _1 = _4 * 16; > _2 = data_10 + _1; > _3 = drand48 (); > _2->x = _3; > i_

Re: LTO slows down calculix by more than 10% on aarch64

On Fri, Aug 28, 2020 at 1:17 PM Prathamesh Kulkarni wrote: > > On Wed, 26 Aug 2020 at 16:50, Richard Biener > wrote: > > > > On Wed, Aug 26, 2020 at 12:34 PM Prathamesh Kulkarni via Gcc > > wrote: > > > > > > Hi, > > > We're seeing

Re: Test case for improving PTA precision

On Fri, Aug 28, 2020 at 1:24 PM Erick Ochoa wrote: > > Hi, > > I'm testing the precision of IPA-PTA when compiling with -flto. I found > this case when a global variable is marked as escaping even if the > variable is a primitive type and no address is taken. > > This is the result of IPA-PTA whic

Re: [GSoC] Automatic Parallel Compilation Viability -- Final Report

On Fri, Aug 28, 2020 at 10:32 PM Giuliano Belinassi wrote: > > Hi, > > This is the final report of the "Automatic Parallel Compilation > Viability" project. Please notice that this report is pretty > similar to the delivered from the 2nd evaluation, as this phase > consisted of mostly rebasing an

Re: [GSoC] Automatic Parallel Compilation Viability -- Final Report

On Mon, Aug 31, 2020 at 1:15 PM Jan Hubicka wrote: > > > On Fri, Aug 28, 2020 at 10:32 PM Giuliano Belinassi > > wrote: > > > > > > Hi, > > > > > > This is the final report of the "Automatic Parallel Compilation > > > Viability" project. Please notice that this report is pretty > > > similar to

Re: [GSoC] Automatic Parallel Compilation Viability -- Final Report

On August 31, 2020 6:21:27 PM GMT+02:00, Giuliano Belinassi wrote: >Hi, Richi. > >On 08/31, Richard Biener wrote: >> On Mon, Aug 31, 2020 at 1:15 PM Jan Hubicka wrote: >> > >> > > On Fri, Aug 28, 2020 at 10:32 PM Giuliano Belinassi >> > > wrote:

Re: [RFC] Add new flag to specify output constraint in match.pd

On Mon, Aug 24, 2020 at 8:20 AM Feng Xue OS via Gcc wrote: > > >> There is a match-folding issue derived from pr94234. A piece of code > >> like: > >> > >> int foo (int n) > >> { > >> int t1 = 8 * n; > >> int t2 = 8 * (n - 1); > >> > >> return t1 - t2; > >> } > >> > >> It

Re: [RFC] Add new flag to specify output constraint in match.pd

On Wed, Sep 2, 2020 at 9:27 AM Marc Glisse wrote: > > On Wed, 2 Sep 2020, Richard Biener via Gcc wrote: > > > On Mon, Aug 24, 2020 at 8:20 AM Feng Xue OS via Gcc wrote: > >> > >>>> There is a match-folding issue derived from pr94234. A piece of code &g

Re: [RFC] Add new flag to specify output constraint in match.pd

On Wed, Sep 2, 2020 at 9:35 AM Feng Xue OS wrote: > > > > >> > >> >> There is a match-folding issue derived from pr94234. A piece of code > >> >> like: > >> >> > >> >> int foo (int n) > >> >> { > >> >> int t1 = 8 * n; > >> >> int t2 = 8 * (n - 1); > >> >> > >> >> return t1 -

Re: Question about exporting omputing alias sets

On Wed, Sep 2, 2020 at 10:04 AM Erick Ochoa wrote: > > Hello, > > I am trying to find out all pointers which alias a pointer and place > them in a set. > > I am using `ptr_derefs_may_alias_p` to find out if two pointers may > point to the same memory location. I think this yields conservative > re

Re: Types are confused in inlining

On Wed, Sep 2, 2020 at 10:19 PM Gary Oblock via Gcc wrote: > > I'm not accusing inlining of having problems but I really > need to understand what's going on in this situation so I can > fix my optimization. > > The error given is: > main.c: In function ‘main’: > main.c:5:1: error: non-trivial con

Re: Is there a way to look for a tree by its UID?

On Thu, Sep 3, 2020 at 10:58 AM Jakub Jelinek via Gcc wrote: > > On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote: > > So, I am just wondering is there an interface where I could do something > > like: > > > > ``` > > // vars is the field in pt_solution of type bitmap > > EXECUT

Re: Types are confused in inlining

nt Ubuntu release >on an Intel I7 core this wouldn't be the case??? I never had an issue with watch points. Richard. >Thanks, > >Gary > >From: Richard Biener >Sent: Wednesday, September 2, 2020 11:31 PM >To: Gary Oblock >Cc: gcc

Re: about souce code location

On Fri, Sep 4, 2020 at 2:23 AM 易会战 via Gcc wrote: > > I am working a instrumention tool, and need get the location info for a > gimple statement. I use the location structure to get the info, and it can > work when i use -O1. When I use -O2, sometimes the info seems to be lost and > I get line

Re: A silly question regarding function types

On Fri, Sep 4, 2020 at 4:39 AM Gary Oblock via Gcc wrote: > > Note, isn't a problem, rather, it's something that puzzles me. > > On walking a function types argument types this way > > for ( arg = TYPE_ARG_TYPES ( func_type); >arg != NULL; >arg = TREE_CHAIN ( arg)) > { >

Re: Is there a way to look for a tree by its UID?

On Fri, Sep 4, 2020 at 10:13 AM Erick Ochoa wrote: > > > > On 03/09/2020 12:19, Richard Biener wrote: > > On Thu, Sep 3, 2020 at 10:58 AM Jakub Jelinek via Gcc > > wrote: > >> > >> On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote: > >

Re: A couple GIMPLE questions

On September 6, 2020 9:38:45 AM GMT+02:00, Gary Oblock via Gcc wrote: >>That's not a question? Are you asking why PHIs exist at all? >>They are the standard way to represent merging in SSA >>representations. You can iterate on the PHIs of a basic block, etc. > >Marc, > >I first worked with the SS

Re: Is there a way to look for a tree by its UID?

On Fri, Sep 4, 2020 at 4:36 PM Erick Ochoa wrote: > > > > On 04/09/2020 15:19, Richard Biener wrote: > > On Fri, Sep 4, 2020 at 10:13 AM Erick Ochoa > > wrote: > >> > >> > >> > >> On 03/09/2020 12:19, Richard Biener wrote: > >>

Re: A problem with one instruction multiple latencies and pipelines

On Mon, Sep 7, 2020 at 8:10 AM Qian, Jianhua wrote: > > Hi > > I'm adding a new machine model. I have a problem when writing the > "define_insn_reservation" for instruction scheduling. > How to write the "define_insn_reservation" for one instruction that there are > different latencies and pipel

Re: A problem with one instruction multiple latencies and pipelines

On Mon, Sep 7, 2020 at 10:46 AM Qian, Jianhua wrote: > > Hi Richard > > > -Original Message- > > From: Richard Biener > > Sent: Monday, September 7, 2020 3:41 PM > > To: Qian, Jianhua/钱 建华 > > Cc: gcc@gcc.gnu.org > > Subject: Re: A proble

Re: Question about instrumenting gimple

On Tue, Sep 15, 2020 at 5:14 PM Erick Ochoa wrote: > > Hi, > > I am trying to instrument gimple so that "hello world" is printed after > each call to malloc. I've tried instrumenting using the following code > > static void > // G points to the gcall which corresponds to malloc > call_hello_world(

Re: Import license issue

On Mon, Sep 21, 2020 at 10:55 AM Andrew Stubbs wrote: > > Ping. Sorry, but you won't get any help resolving license issues from the mailing list. Instead you should eventually ask the SC to "resolve" this issue with the FSF. Richard. > On 14/09/2020 17:56, Andrew Stubbs wrote: > > Hi All, > > >

Re: LTO slows down calculix by more than 10% on aarch64

On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni wrote: > > On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni > wrote: > > > > On Mon, 21 Sep 2020 at 15:19, Prathamesh Kulkarni > > wrote: > > > > > > On Fri, 4 Sep 2020 at 17:08, Alexander Monakov wrote: > > > > > > > > > I obtained perf stat

Re: LTO slows down calculix by more than 10% on aarch64

On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni wrote: > > On Tue, 22 Sep 2020 at 12:56, Richard Biener > wrote: > > > > On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni > > wrote: > > > > > > On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulk

Re: LTO slows down calculix by more than 10% on aarch64

On Tue, Sep 22, 2020 at 6:25 PM Prathamesh Kulkarni wrote: > > On Tue, 22 Sep 2020 at 16:36, Richard Biener > wrote: > > > > On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni > > wrote: > > > > > > On Tue, 22 Sep 2020 at 12:56, Richard Biener

Re: LTO slows down calculix by more than 10% on aarch64

On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni wrote: > > On Wed, 23 Sep 2020 at 13:22, Richard Biener > wrote: > > > > On Tue, Sep 22, 2020 at 6:25 PM Prathamesh Kulkarni > > wrote: > > > > > > On Tue, 22 Sep 2020 at 16:36, Richard Biener

Re: LTO slows down calculix by more than 10% on aarch64

On Thu, Sep 24, 2020 at 12:36 PM Prathamesh Kulkarni wrote: > > On Wed, 23 Sep 2020 at 16:40, Richard Biener > wrote: > > > > On Wed, Sep 23, 2020 at 12:11 PM Prathamesh Kulkarni > > wrote: > > > > > > On Wed, 23 Sep 2020 at 13:22, Richard Biener

Re: On IPA-PTA field sensitivity and pointer expressions

On Fri, Sep 25, 2020 at 9:05 AM Erick Ochoa wrote: > > Hi, > > I am working on an alias analysis using the points-to information > generated during IPA-PTA. If we look at the varmap varinfo_t array in > gcc/tree-ssa-struct.c, most of the constraint variable info structs > contain a non-null decl f

Re: On IPA-PTA field sensitivity and pointer expressions

On Fri, Sep 25, 2020 at 2:27 PM Erick Ochoa wrote: > > > > On 25/09/2020 13:30, Richard Biener wrote: > > On Fri, Sep 25, 2020 at 9:05 AM Erick Ochoa > > wrote: > >> > >> Hi, > >> > >> I am working on an alias analysis using the points

Re: Git rejecting branch merge

On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote: > > Hello, > I am trying to update me/honza-gcc-benchmark-branch to current trunk > which I do by deleting it, recreating locally and pushing out. > > The problem is that the push fails witih: > > remote: *** The following commit was rejected by y

Re: Git rejecting branch merge

On Tue, Sep 29, 2020 at 11:11 AM Jan Hubicka wrote: > > > On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote: > > > > > > Hello, > > > I am trying to update me/honza-gcc-benchmark-branch to current trunk > > > which I do by deleting it, recreating locally and pushing out. > > > > > > The problem i

Re: Is there a way to tell GCC not to reorder a specific instruction?

On Tue, Sep 29, 2020 at 12:55 PM 夏 晋 via Gcc wrote: > > Hi everyone, > I tried to set the "vlen" after the add & multi, as shown in the following > code: > ➜ > vf32 x3,x4; > void foo1(float16_t* input, float16_t* output, int vlen){ > vf32 add = x3 + x4; > vf32 mul = x3 * x4; > __built

Re: Is there a way to tell GCC not to reorder a specific instruction?

On Tue, Sep 29, 2020 at 9:46 PM Jim Wilson wrote: > > On Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc wrote: > > I tried to set the "vlen" after the add & multi, as shown in the following > > code: > > > vf32 x3,x4; > > void foo1(float16_t* input, float16_t* output, int vlen){ > > vf32 add = x3

Re: Is there a way to tell GCC not to reorder a specific instruction?

On Wed, Sep 30, 2020 at 10:01 PM Jim Wilson wrote: > > On Tue, Sep 29, 2020 at 11:40 PM Richard Biener > wrote: > > But this also doesn't work on GIMPLE. On GIMPLE riscv_vlen would > > be a barrier for code motion if you make it __attribute__((returns_twice)) >

Re: GCC DWARF Issue - Frame Pointer Dependency

On Tue, Oct 13, 2020 at 5:10 AM AJ D via Gcc wrote: > > Hi, > > > > I have a function for which GCC is generating the following code (just > showing the relevant snippet here). > > > > 5a70 : > > 5a70: 4c 8d 54 24 08 lea0x8(%rsp),%r10 > > 5a75: 48 83 e4 f0

Re: Question about callgraph and call_stmt

On Tue, Oct 13, 2020 at 1:17 PM Erick Ochoa wrote: > > Hi, > > I am analyzing gimple calls during LTO. What's symtab->state at this point? >I found a gimple call statement > s that has the following properties: > > ``` > tree fndecl = gimple_call_fndecl(s) > gcc_assert(fndecl) > // That is, the

<    15   16   17   18   19   20   21   22   23   24   >