Hi, this refers to https://gcc.gnu.org/ml/gcc/2019-11/msg00251.html
On 2019-12-04 6:30 a.m., Martin Liška wrote:
> Hello.
>
> I'm adding the author of IPA CP and LTO subsystem maintainer.
>
> Martin
On 2019-12-04 7:52 a.m., Richard Biener wrote:
> On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
> wrote:
>>
>> Hi,
>>
>> I am trying to use the function: `cgraph_node::get_untransformed_body` during
>> the wpa stage of a SIMPLE_IPA_PASS transformation. Whi
nction),
+};
+
+class pass_ipa_initcall_cp : public ipa_opt_pass_d
+{
+public:
+ pass_ipa_initcall_cp (gcc::context *ctxt)
+: ipa_opt_pass_d (pass_data_ipa_initcall_cp, ctxt, NULL, NULL, NULL, NULL,
+ NULL, NULL, 0, NULL, NULL)
+ {}
+
+ /* opt_pass methods: */
+ virtual b
Hello,
I am trying to understand how to store information in object files
during LTO.
Is it possible to write arbitrary data in these sections?
There's not a lot of documentation about the specifics I need in the GCC
Internals.
I have made a simple LTO pass that writes
* "Hello world\n" into
Hello,
I am working on a struct reorganization optimization pass.
I am able to identify which structs I want to reorganize
and I am also able to create new structs with these modifications.
The way the new structs are generated is the following code
(I am keeping it high-level for conciseness but
Hi,
I'm interested in printing VAR_DECL trees that are of type
RECORD_TYPE. I am using the function print_generic_decl
for debugging and found this interesting behaviour.
When I do initialization of structs using the following
syntax:
```
struct aStruct { _Bool e; int a; char b; float c; double
On 2019-12-06 5:50 a.m., Richard Biener wrote:
> On Wed, Dec 4, 2019 at 6:03 PM Erick Ochoa
> wrote:
>>
>>
>>
>> On 2019-12-04 7:52 a.m., Richard Biener wrote:
>>> On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
>>> wrote:
>>>>
>
Hi,
I am trying to use the function: `cgraph_node::get_untransformed_body` during
the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function
is running, I need to access the body of a function in order to iterate over
the gimple instructions in the first basic block. I have
Hello,
my name is Erick and I am working in a link-time-optimization pass named
ipa-initcall-cp. It is called ipa-initcall-cp because it propagates constant
values written to variables with static lifetimes (such as ones initialized in
initialization functions). ipa-initcall-cp has to be located
On 2019-12-18 1:33 p.m., Erick Ochoa wrote:
>
>
> On 2019-12-18 6:02 a.m., Richard Biener wrote:
>> On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa
>> wrote:
>>> Hi,
>>>
>>> I'm interested in printing VAR_DECL trees that are
Hi,
I'm looking to create new tests for an LTO pass that I'm working on.
So, I started by trying to run the tests under the folder:
$gcc/gcc/testsuite/gcc.dg/lto
Looking at the documentation available here:
https://gcc.gnu.org/install/test.html
It says the following
In order to run sets of
On 2019-12-19 3:50 p.m., Andrew Pinski wrote:
> On Thu, Dec 19, 2019 at 12:48 PM Erick Ochoa
> wrote:
>>
>> Hi,
>>
>> I'm looking to create new tests for an LTO pass that I'm working on.
>> So, I started by trying to run the tests under the fold
Hello,
I am working on testing an optimization. I am starting to write
tests in the GCC testing suite. However, I want to develop some
fine grain testing for my own sake.
This optimization I am working on, is a variant of struct reordering.
One way I would like to test my pass is for example,
On 2019-12-19 5:01 p.m., Jozef Lawrynowicz wrote:
> On Thu, 19 Dec 2019 16:47:42 -0500
> Erick Ochoa wrote:
>
>> Hello,
>>
>> I am working on testing an optimization. I am starting to write
>> tests in the GCC testing suite. However, I want to develop some
On 2019-12-18 6:02 a.m., Richard Biener wrote:
> On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa
> wrote:
>> Hi,
>>
>> I'm interested in printing VAR_DECL trees that are of type
>> RECORD_TYPE. I am using the function print_generic_decl
>> for
Hello,
I have a problem with a transformation I'm working on and I would appreciate
some help. The transformation I am working on removes fields in structs early
during link-time. For the purposes of development and this example, my
transformation deletes the field identified as "delete_me" from
Hi Richard,
Thanks! I can confirm that changing VAR_DECL's type
and calling relayout_decl fixes my problem.
On 2020-01-28 4:35 a.m., Richard Biener wrote:
> On Mon, Jan 27, 2020 at 6:41 PM Erick Ochoa
> wrote:
>>
>> Hello,
>>
>> I have a problem with a transformat
On 2019-12-24 2:37 a.m., Richard Biener wrote:
> On December 23, 2019 6:30:31 PM GMT+01:00, Erick Ochoa
> wrote:
>> Hi,
>>
>> I am working on an LTO pass which drops unused fields on structs. On my
>> tests, I found that the gimple generated for `sizeof` is
Hi,
I am working on an LTO pass which drops unused fields on structs. On my
tests, I found that the gimple generated for `sizeof` is a constant. For
example, for the following C code:
```
struct astruct_s { _Bool c; _Bool a; _Bool b; };
struct astruct_s astruct;
int
main()
{
int size =
Hello,
I am trying to find out the arguments of functions which are undefined
during LTO.
Basically:
gcc_assert(in_lto_p && !cnode->definition)
// Do we have arguments?
gcc_assert(DECL_ARGUMENTS(cnode->decl)) // fails
// No, we don't.
As I understand it, functions which are not defined are
Hello,
Can someone help me understand better GCC's profile driven
instrumentation? I know this can be a long topic, but I am not looking
for a long discussion. I am just trying to orient myself regarding GCC's
FDO implementation.
1. I know that gcc uses an instrumentation based profiler.
xtern simple_ipa_opt_pass *make_pass_ipa_free_lang_data (gcc::context
*ctxt);
extern simple_ipa_opt_pass *make_pass_ipa_free_fn_summary
(gcc::context *ctxt);
+extern simple_ipa_opt_pass *make_pass_ipa_hello_world (gcc::context *ctxt);
extern ipa_opt_pass_d *make_pass_ipa_cp (gcc::context *ctxt);
On 07/04/2020 14:34, Michael Matz wrote:
Hello,
On Tue, 7 Apr 2020, Erick Ochoa wrote:
Thanks for this lead! It is almost exactly what I need. I do have one more
question about this. It seems that the types obtained via
FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when
On 13.03.20 00:44, Richard Biener wrote:
On Thu, Mar 12, 2020 at 5:31 PM Erick Ochoa
wrote:
Hello,
I am trying to find out the arguments of functions which are undefined
during LTO.
Basically:
gcc_assert(in_lto_p && !cnode->definition)
// Do we have arguments?
gcc_assert(DEC
On 12.03.20 08:48, Jan Hubicka wrote:
Hello,
Hello,
I am trying to find out the arguments of functions which are undefined
during LTO.
Basically:
gcc_assert(in_lto_p && !cnode->definition)
// Do we have arguments?
gcc_assert(DECL_ARGUMENTS(cnode->decl)) // fails
// No, we don't.
As I
p_vectorize, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_funswitch_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL,
VECT_COST_MODEL_DYNAMIC },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fversion_loops_for_strides, NULL, 1 },
On 22.04.2020, at 16:01, Erick Ochoa wrote:
Hello,
Does anyone know if the following text from the GCC internals [0] is
outdated?
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2
and also turns on the following optimization flags:
-fgcse-after-reload
-fipa-cp-clone
-floop-interchange
On 22/04/2020 16:25, Jakub Jelinek wrote:
On Wed, Apr 22, 2020 at 04:17:56PM +0200, Philipp Tomsich wrote:
ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and
Hi,
Does the analysis framework available in GCC 10 is an instance of an
IFDS or an IDE framework? The Analyzer Internals [0] refers to the IFDS
paper [1], but I am not sure if this is only to provide a reference to
the definition of exploded supergraph.
Also, if I want to implement my own
On 06/05/2020 18:40, Richard Biener wrote:
On Wed, May 6, 2020 at 3:04 PM Erick Ochoa
wrote:
On 06/05/2020 14:25, Richard Biener wrote:
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I would like to find a function that given an
allocation site, the return value is a set of pointers which may point
to memory allocated from that allocation site.
For example:
int
main(int argc,
On 06/05/2020 14:25, Richard Biener wrote:
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I would like to find a function that given an
allocation site, the return value is a set of pointers
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:
So, I am just wondering is there an interface where I could do something
like:
```
// vars is the field in pt_solution
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
results (i.e., when it cannot be proven that to pointers may
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(gimple* g)
{
gimple_stmt_iterator gsi = gsi_start(g);
//
Thanks Richard,
for sake of completeness (and anyone in the future looks for a simple
hello world example), here's what my code roughly looks like:
push_cfun(f); // f is the function who calls malloc
static void
call_hello_world(gimple* g)
{
gimple_stmt_iterator gsi = gsi_start(g);
const
Hi Gary,
I'm not 100% sure this will fix the problem, but in the past I have had
to call the following function:
/* If dominator info is not available, we need to calculate it. */
if (!dom_info_available_p (CDI_DOMINATORS))
calculate_dominance_info (CDI_DOMINATORS);
Basically
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:
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
I think every SSA_NAME variable has a:
* ptr_info_def*
* which points to a pt_solution
* which points to a bitmap field vars
and I think this bitmap vars is set with 1 in the UID location of
variables/references that an SSA_NAME variable might point to it.
So, I am just wondering is there an
Hi,
I am analyzing gimple calls during LTO. I found a gimple call statement
s that has the following properties:
```
tree fndecl = gimple_call_fndecl(s)
gcc_assert(fndecl)
// That is, the gimple call returns a non-null fndecl.
cgraph_node *n = cgraph_node::get(fndecl);
gcc_assert(!n)
// That
On 13/10/2020 13:37, Richard Biener wrote:
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?
The state is IPA_SSA_AFTER_INLINING.
I found a gimple call statement
s that has the following propert
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:
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
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,
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
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 subfields will escape.
To do this, I made a program that has a global
On 25/08/2020 17:10, Richard Biener wrote:
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
On 25/08/2020 22:03, Richard Biener wrote:
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,
I'm trying to understand how
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 which I believe is wrong.
buff2 = { ESCAPED NONLOCAL }
buff1 = {
to make this easier for you to review do let us
know.
Thanks,
Tamar
-Original Message-
From: Erick Ochoa
Sent: Monday, August 17, 2020 2:53 PM
To: GCC Development
Cc: Christoph Müllner ;
philipp.toms...@theobroma-systems.com; Tamar Christina
; Kevin Smith
; Gary Oblock
; Richard Biener
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 D.[0-9]* is appended to some gimple variables.
I initially imagined
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-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
Hello again,
I have committed a couple of changes to the branch
refs/vendors/ARM/heads/arm-struct-reorg-wip
where my transformations are currently residing. This week I'll be
working on fixing several warnings and fuzzying these passes.
2020-08-17 Erick Ochoa
* Can be bootstrapped
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 the
points_to_set(s) (computed by IPA-PTA)?
My intuition tells
On 28/09/2020 14:25, Erick Ochoa wrote:
Hi,
previously I sent an e-mail inquiring about the state of points-to
information of structure variables allocated in the heap. It was brought
to my attention that heap variables do not have a size to model and
therefore IPA-PTA is not able
Hi,
previously I sent an e-mail inquiring about the state of points-to
information of structure variables allocated in the heap. It was brought
to my attention that heap variables do not have a size to model and
therefore IPA-PTA is not able to provide field sensitivity.
I now understand
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 field which points to a valid tree in gimple
(which is an
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-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
} same as p1.128+64
temp2_34 = { c }
Thanks!
On 28/09/2020 14:30, Erick Ochoa wrote:
On 28/09/2020 14:25, Erick Ochoa wrote:
Hi,
previously I sent an e-mail inquiring about the state of points-to
information of structure variables allocated in the heap. It was
brought to my attention
Hello again,
Thanks for replying to my previous thread. I am thankful for all input
received and addressed the comments which I could address. I have been
working on the past two weeks on fixing the style and adding comments
explaining classes and families of functions. I have also added a
Hello,
I'm working on an optimization and I encountered this interesting
behaviour. There are a couple of functions that are specialized when the
program is not compiled with PGO (-fprofile-generate and -fprofile-use)
However, when the program is compiled with PGO the compiler does not
Forgot to mention that these functions take a function pointer as a
parameter and as a result, the specialized functions are able to replace
the indirect function call with a direct function call.
On 10/07/2020 13:17, Erick Ochoa wrote:
Hello,
I'm working on an optimization and I encountered
. This parameter is used for both: function specialization within
a particular context and for all contexts.
On 10/07/2020 13:19, Erick Ochoa wrote:
Forgot to mention that these functions take a function pointer as a
parameter and as a result, the specialized functions are able to replace
On 13/07/2020 13:13, Martin Jambor wrote:
Hi,
On Fri, Jul 10 2020, Erick Ochoa wrote:
Hello,
is there a way to determine just how an argument is affected by SRA
after SRA has occured?
How would I be able to determine the effects of ISRA on the struct argument?
For the changes performed
Hello,
is there a way to determine just how an argument is affected by SRA
after SRA has occured? I have the following functions:
source:
_Bool
returnLastField (struct arc anArc)
{
return anArc.c;
}
_Bool
returnNextField (struct arc anArc)
{
_Bool *ptr = &(anArc.a);
ptr = ptr + 1; //
Hello,
I have a function foo defined on a source file. Sometimes, a function
pointer pointing to foo is passed as a parameter to other functions
where foo is called indirectly. This indirect call is specialized during
link time. Still at link time, I analyze the function call the following
?
Thanks.
On 14/07/2020 12:37, Erick Ochoa wrote:
Hello,
I have a function foo defined on a source file. Sometimes, a function
pointer pointing to foo is passed as a parameter to other functions
where foo is called indirectly. This indirect call is specialized during
link time. Still at link time
On 15.07.20 05:03, Martin Jambor wrote:
Hi,
On Tue, Jul 14 2020, Erick Ochoa wrote:
On 14/07/2020 12:37, Erick Ochoa wrote:
Hello,
I have a function foo defined on a source file. Sometimes, a function
pointer pointing to foo is passed as a parameter to other functions
where foo is called
.
Is it the desired behaviour that functions which addresses are taken to
be marked as unreachable (and therefore being unregistered from the
symbol table)?
If needed I can reduce the problem, but I don't want to do it if this is
the intended behaviour.
Thanks!
On 14.07.20 04:19, Erick Ochoa wrote:
Actually
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:
Implementations of sizeof and offsetof that support this change in
On 29.06.20 04:08, Richard Biener wrote:
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 close to sharing
On 29.06.20 04:05, 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 close to sharing the results we
have so far, but there are a couple of missing
On 29.06.20 06:05, Martin Jambor wrote:
Hi,
On Mon, Jun 29 2020, Erick Ochoa wrote:
== How do we get what we want? ==
Ideally what we want is to:
[...]
* Disable constant propagation and other optimizations:
* possibly __attribute__((noipa))
[...]
== What's the WORST CASE
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 components:
Type-based escape analysis to determine if
On 16/07/2020 12:11, Martin Jambor wrote:
Hi,
On Wed, Jul 15 2020, Erick Ochoa wrote:
On 15.07.20 05:03, Martin Jambor wrote:
[...]
At IPA time, the best way is always to look at the call graph edges,
something like:
cgraph_edge *cs = caller_cgraph_node->get_edge (s);
exam
On 27/07/2020 14:36, Richard Biener wrote:
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
Hi,
is there a way to find out that a function is a clone of another
function after materialization? I believe that `clone_of_p` only works
before materialization. I tried and no clones were detected.
Thanks!
an
issue.
After this, I will be removing std data structures and using specific ones.
If anyone have any comments about the transformation, please let me
know. I am happy to answer questions.
-Erick
On 06.11.20 05:51, Erick Ochoa wrote:
Hi Richard,
just some top-level comments before I write about
these designs were made.
On 03/11/2020 15:58, Richard Biener wrote:
On Fri, Oct 30, 2020 at 6:44 PM Erick Ochoa
wrote:
Hello again,
I've been working on several implementations of data layout
optimizations for GCC, and I am again kindly requesting for a review of
the type escape based dead field
Hello again,
I've been working on several implementations of data layout
optimizations for GCC, and I am again kindly requesting for a review of
the type escape based dead field elimination and field reorg.
Thanks to everyone that has helped me. The main differences between the
previous
the visitors.
On 05/11/2020 14:10, Richard Biener wrote:
On Tue, Nov 3, 2020 at 5:21 PM Erick Ochoa
wrote:
Thanks for the review Richard I'll address what I can. I also provide
maybe some hindsight into some of the design decisions here. I'm not
trying to be defensive just hoping to illuminate
?id=92538
2019-11-15 Erick Ochoa
Proposal for IPA init() constant propagation
* gcc/Makefile.in: Add pass to the build process
* gcc/cgraph.c: Add assertion.
* gcc/common.opt: Add pass
* gcc/ipa-initcall-cp.c: new
* gcc/passes.def: Place pass
Forgot to attach the test cases.
On 2020-01-23 10:20 a.m., Erick Ochoa wrote:
> Hi Jan,
>
> Here is a patch I just rebased against
>
> commit 2589beb1d1a065f75a5515c9e2698de12a421913 (origin/master, origin/HEAD,
> master)
> Author: GCC Administrator
> Date: Sun Ja
Hi Jan,
Here is a patch I just rebased against
commit 2589beb1d1a065f75a5515c9e2698de12a421913 (origin/master, origin/HEAD,
master)
Author: GCC Administrator
Date: Sun Jan 19 00:16:30 2020 +
I also include some test cases.
To run test cases, just set your path for the gcc
executable
Hello,
I noted that the optimizations turned on by O3 was outdated in the
documentation. Here is the discussion that brought it to my attention:
https://gcc.gnu.org/pipermail/gcc/2020-April/232164.html
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e2bc2559218..a28001a5adf
Fixes documentation for gimple_assign functions
This patch corrects the documented function signatures of gimple_assign*
functions.
ChangeLog:
2020-05-16 Erick Ochoa
* gcc/gimple.h (gimple_assign_rhs_code): Fix signature
(gimple_assign_rhs_class): same
. The wrapper takes gimple* as arguments.
ChangeLog:
2020-05-16 Erick Ochoa
* gcc/gimple.h (gimple_return_retval): New function
(gimple_return_retval_ptr): same
(gimple_return_set_retval): same
* gcc/gimple.texi (gimple_return_retval): Fix documentation
wrote:
On May 16, 2020 11:42:02 AM GMT+02:00, Erick Ochoa
wrote:
Fixes documentation for gimple_assign functions
This patch corrects the documented function signatures of
gimple_assign*
functions.
OK.
Richard.
ChangeLog:
2020-05-16 Erick Ochoa
* gcc/gimple.h
This patch fixes some quotations inside comments. The change in syntax
highlighting was bothering me. I also found a typo.
ChangeLog:
2020-05-06 Erick Ochoa
* gcc/tree-ssa-struct-alias.c: Fix comments
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index
---
gcc/ipa-ref.c | 22 ++
gcc/ipa-ref.h | 3 +++
2 files changed, 25 insertions(+)
diff --git a/gcc/ipa-ref.c b/gcc/ipa-ref.c
index 241828ee973..76459e9cc3d 100644
--- a/gcc/ipa-ref.c
+++ b/gcc/ipa-ref.c
@@ -103,3 +103,25 @@ ipa_ref::referred_ref_list (void)
{
---
gcc/tree.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/tree.h b/gcc/tree.h
index bd0c51b2a18..86a4542f58b 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -6156,6 +6156,17 @@ int_bit_position (const_tree field)
+ wi::to_offset (DECL_FIELD_BIT_OFFSET
Hello everyone,
I wanted to highlight this ticket on bugzilla [0]. It is a missed
optimization that I worked on. It involves propagating constants across
function calls at link-time. I am relatively new to GCC and this would
be my first significant contribution. I have developed a prototype
This pass is a variant of constant propagation where global
primitive constants with a single write are propagated to multiple
read statements.
ChangeLog:
2020-05-20 Erick Ochoa
gcc/Makefile.in: Adds new pass
gcc/passes.def: Same
gcc/tree-pass.h: Same
gcc
---
gcc/ipa-ref.h| 2 +-
gcc/ipa-visibility.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/ipa-ref.h b/gcc/ipa-ref.h
index 95e29605548..9ff26e2693c 100644
--- a/gcc/ipa-ref.h
+++ b/gcc/ipa-ref.h
@@ -139,5 +139,5 @@ public:
const char *
---
gcc/ipa-utils.c | 33 +
gcc/ipa-utils.h | 4 +++-
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/gcc/ipa-utils.c b/gcc/ipa-utils.c
index 23e7f714306..bd3e79bd2e2 100644
--- a/gcc/ipa-utils.c
+++ b/gcc/ipa-utils.c
@@ -781,3 +781,36 @@
On 02/06/2020 14:29, Richard Biener wrote:
On Sat, May 30, 2020 at 12:18 AM Jan Hubicka wrote:
---
gcc/tree.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/tree.h b/gcc/tree.h
index bd0c51b2a18..86a4542f58b 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -6156,6
---
gcc/ipa-dfe.c | 262 +++---
gcc/ipa-dfe.h | 108 +++---
gcc/ipa-field-reorder.c| 134 +++
gcc/ipa-type-escape-analysis.c | 636 -
gcc/ipa-type-escape-analysis.h | 160 -
5 files changed, 643
then we color the nodes in the call graph
as "casts are safe in this function and does not call external
visible functions". We propagate this property up the callgraph
until a fixed point is reached. This will later be changed to
use ipa-modref.
2020-11-04 Erick Ochoa
* ipa-t
---
gcc/common.opt| 4 ++
gcc/ipa-type-escape-analysis.c| 11 +
.../ipa/ipa-access-counter-00-simple-read-0.c | 22 ++
.../ipa-access-counter-01-simple-write-0.c| 22 ++
.../ipa-access-counter-02-pointer-read-0.c| 22
2020-11-04 Erick Ochoa
* ipa-field-reorder: Add flag to exit transformation.
* ipa-type-escape-analysis: Same.
---
gcc/ipa-field-reorder.c| 3 +-
gcc/ipa-type-escape-analysis.c | 54 --
gcc/ipa-type-escape-analysis.h | 2 ++
3 files changed
of the current linking unit (e.g. parameter types of
external
functions).
The field access analyses non-escaping structs for fields that
are not used in the linking unit and thus can be removed.
2020-11-04 Erick Ochoa
* Makefile.in: Add file to list of new sources.
* common.opt: Add new
Using the Dead Field Analysis, Dead Field Elimination
automatically transforms gimple to eliminate fields that
are never read.
2020-11-04 Erick Ochoa
* Makefile.in: Add file to list of sources.
* ipa-dfe.c: New.
* ipa-dfe.h: Same.
* ipa-type-escape-analysis.h: Export code
1 - 100 of 196 matches
Mail list logo
