Erick my friend,
That's exactly why I'm such a big fan of creating things
anew each time I mess with them.
Later,
Gary
From: Erick Ochoa
Sent: Tuesday, March 8, 2022 7:29 AM
To: Martin Jambor
Cc: gcc@gcc.gnu.org
Subject: Re: Question on updating function
ubject: Re: What replaces FOR_EACH_LOOP_FN
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Wed, Mar 2, 2022 at 2:05 PM Gary Oblock via Gcc wrote:
>
> Guys,
>
Guys,
I've been working on an optimization for quite a bit of time and
in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN
no longer exists. I poked around in the archives and tried a Google
search but found nothing on it.
It suited my needs and I'd hate to have to rewrite a bunch
to not trigger
the special behavior in GCC?
Andras
On Mon, 2022-02-21 at 03:19 +, Gary Oblock via Gcc wrote:
> Trying to use the dhrystone isn't going to be very useful. It has
> many downsides not the least is that gcc's optimizer can run rings
> about it.
Trying to use the dhrystone isn't going to be very useful. It has many
downsides not the least is that gcc's optimizer can run rings about it.
Gary
From: Gcc on behalf of
gcc-requ...@gcc.gnu.org
Sent: Tuesday, February 15, 2022 6:25 AM
To: gcc@gcc.gnu.org
, 2022 at 9:12 AM Gary Oblock via Gcc wrote:
>
> An optimization flag that I recently added is being
> set to zero in push_cfun (which after a couple of
> levels of calls cl_optimization_restore to this.)
>
> The flag defined like this:
>
> finterleaving-in
Gabriel,
Yes, indeed, thank you.
Note, it is a reminder to those that are receiving proprietary
and that is considered as a legal obligation on the part of the
company transmitting it because they must make an effort to
protect their proprietary information.
I'm not a lawyer either but I feel
: Issue with a flag that I defined getting set to zero
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On 1/7/22 09:10, Gary Oblock via Gcc wrote:
> An optimization flag that I recen
An optimization flag that I recently added is being
set to zero in push_cfun (which after a couple of
levels of calls cl_optimization_restore to this.)
The flag defined like this:
finterleaving-index-32-bits
Common Var(flag_interleaving_index_32_bits) Init(0) Optimization
Structure
ary Oblock
> Cc: gcc@gcc.gnu.org
> Subject: Re: Why do these two trees print differently
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
> be mindful of safe email handling and proprietary information protection
> practices.]
>
>
Biener
Sent: Monday, January 3, 2022 5:49 AM
To: Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: Why do these two trees print differently
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practic
This is one of those things that has always puzzled
me so I thought I break down and finally ask.
There are two ways a memory reference (tree) prints:
MEM[(struct arc_t *)_684].flow
and
_684->flow
Poking under the hood of them, the tree codes and
operands are identical so what am I missing?
r 1, 2021 1:09 AM
> > To: Gary Oblock
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: odd internal failure
> >
> > [EXTERNAL EMAIL NOTICE: This email originated from an external
> > sender. Please be mindful of safe email handling and proprietary
> > informati
ubject: Re: odd internal failure
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc wrote:
>
> What is happening s
What is happening should be trivial to determine but for some reason it's
not. I'd normally bounce this off a coworker but given the pandemic
and modern dispersed hiring practices it's not even remotely possible.
I'm making this call and tree_to_uhwi is failing on an internal error.
That's
Our test group added "-fchecking" to a script and my optimization
failed.
I can't find any explanation of this type of bug. I grepped the code
and flag_checking was all over the place so it's not like
I can use gdb to pin it down.
Can somebody help me make sense out of this?
lto1: error: type
I suppose I should answer my own question
Yes, the final compiler built has ubsan enabled.
Gary
PS. The faint hearted should note this is an overnight build. It would be nice
if this wasn't tied to building a bootstrap compiler.
From: Gary Oblock
Sent:
Toon,
I assume the final compiler built this way has ubsan? I ask because
I'm trying to spot a bug in a new optimization so I want to
run it on a specific test case with the new optimization
enabled.
Thanks,
Gary
From: Toon Moene
Sent: Monday, September 27,
I tried just adding "-fsanitize=undefined" to my CXX_FLAGS and got
a bunch of errors like this:
/usr/bin/ld: ../libcody/libcody.a(server.o): in function
`std::__cxx11::basic_string, std::allocator
>::_Alloc_hider::~_Alloc_hider()':
/usr/include/c++/9/bits/basic_string.h:150: undefined reference
I've got a really amazingly bizarre bug, when running my modified
gcc under gdb, I see some bewildering behavior. So, before I start
debugging at the assembly level, I'd like to see some .s files.
This led me to try adding "-save-temps" to the CFLAGS and
CXXFLAGS on the make command line. This in
ices.]
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 =
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 a GIMPLE_LABEL and
it has
> {mem_ref<0B>,addr_expr<_basket>}@.MEM_104(D) (0015),
> > {mem_ref<0B>,addr_expr<_group_end_arc>}@.MEM_104(D) (0083),
> > end_arc_445 (0228), {mem_ref<0B>,addr_expr<_p>}@.MEM_104(D) (0016),
> > red_cost_of_bea_42 (0019), bea_43 (0020), dedangled_865 (0
lt;0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> (0312),
> {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> (0327),
> {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reo
gled_868)
goto ; [89.00%]
else
goto ; [11.00%]
=
I was pretty arbitrary here about what I extracted from the
dump file but it's 33MB in size.
I'm still thinking it's something dumb that I did
when I created "dedangled_864" but I ca
I seem to be having a problem with the pre pass.
When eliminate_dom_walker::eliminate_stmt is called with
the gsi to "dedangled_864 = bea_43->tail;" which in turn
calls eliminate_dom_walker::eliminate_avail op of dedangled_864.
This gives VN_INFO (lhs)->valnum of _920. The _920 is not
associated
12:23 AM
To: Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: A simple debugging question
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Wed, Jul 14, 2021 at 6:42 AM Gary Oblock
OK, I haven't asked a dumb question for a while so here goes!
I'm trying to debug my optimization in lto running 505mcf_r
(yes it's SPEC17.)
Here's the bit that fails from the make.out:
/home/gary/gcc_build_gcc11/install/libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto1
-quiet -dumpdir
I've got to say appearances can be deceptive
in GCC and struct _modif_basket *[4061] is not
necessarily equal to struct _modif_basket *[4061]
even though the printed representation is
the same...
Gary
From: Gcc on behalf of gcc-requ...@gcc.gnu.org
Sent:
My jaws hit the floor when I saw this bug:
psimplex.c: In function ‘master.constprop’:
psimplex.c:124:6: error: non-trivial conversion in ‘constructor’
124 | void master(network_t *net, int num_threads)
| ^
struct _modif_basket *[4061]
struct _modif_basket *[4061]
struct
I'm chasing a bug and I used Creduce to produce a
reduced test case. However, that's really beside to
point.
I this file:
typedef struct basket {
} a;
long b;
a *basket;
int d, c, e;
a *flake[2];
void primal_bea_mpp();
void primal_net_simplex() {
flake[1] = [1];
Guys,
I checked out a fresh copy of the GCC sources today, applied somebodies
patch to it and voila!
options.c:13591:2: error: #error Report option property is dropped #error
Report option property is dropped
I built this the same minimally convoluted way that I always do.
cd $1
BASE=`pwd`
Guys,
I've been trying to debug a linker error (which I thought was a bug in
my optimization.) Well it turns out it occurs in a brand new virgin
version of the compiler running with binutils 2.36 which is the latest
version. I'm posting this on both the binutils list and gcc list
because people
I've got collect2 finding a linker error and I'm out of
other options so I'm poking around in the collect2
sources. I'm wondering what pex_run is (since it's
getting handed the arguments this might mater?)
I figure if I can get collect2 to spill its guts
about what arguments are fed to "ld" I'll
from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Tue, Feb 23, 2021 at 1:12 AM Gary Oblock via Gcc wrote:
>
> I'm having a "linker" error (according to Martin Liška) when
> compiling a SPEC test (x264_r) w
I'm having a "linker" error (according to Martin Liška) when
compiling a SPEC test (x264_r) with a vendor branch under development (my
optimization is done at LTO time.)
The binutils on my development machine is the version
that came with Ubuntu 18.02. Do I need to install a more
current
I'm running my new optimization (LTO with one partition)
on a SPEC17 test.
I got the mysterious message
"collect2: error: ld returned 1 exit status"
Now, first off, with my debugging on at full tilt and it's
clear my optimization bailed out after analyzing
the code without doing anything.
The offsets seem to actually be created. However,
they are almost immediately are being deleted.
Any ideas what's going on? Has some kind
of memory management gizmo gone awry?
Gary
PS For anybody who has been following my travails with the instance
interleaving structure
reorganization
I'm having some grief with creating/using some modified types.
I problem occurs in tree-ssa-sccvn.c when some code tries
to take a DECL_FIELD_OFFSET and unfortuenately gets a null
that causes a crash.
So, I traced this back the to types I created. Note, the method I used
has seemed to be fairly
@gcc.gnu.org
Subject: Re: gsi_remove on a call
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Tue, Oct 27 2020, Gary Oblock via Gcc wrote:
> I'm running into grief in verify_n
I'm running into grief in verify_node in cgraph.c
when I use gsi_remove on a call statement.
Specifically it's a free statement which I've replaced
with other free statements as part of my structure
reorg optimizations. Note, in other working code
I do this with malloc and it doesn't seem to be a
ary information protection
practices.]
On Fri, Oct 23, 2020 at 5:10 AM Gary Oblock via Gcc wrote:
>
> I'm finishing up coding my patterns for the structure reorganization
> optimization. They recognize certain instructions and replace them
> other instructions. I've got some code
Never mind... assume I'm grumbling about the documentation.
;-(
Gary
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and contains information that is
confidential and proprietary to Ampere Computing or its subsidiaries.
I'm finishing up coding my patterns for the structure reorganization
optimization. They recognize certain instructions and replace them
other instructions. I've got some code that generates gimple which is
inserted as it's created with gsi_insert_before. This code is
something I'd like to use at
>IPA transforms happens when get_body is called. With LTO this also
>trigger reading the body from disk. So if you want to see all bodies
>and work on them, you can simply call get_body on everything but it will
>result in increased memory use since everything will be loaded form disk
>and
I have a tiny program composed of a few functions
and one of those functions (setupB) has gone missing.
Since I need to walk its GIMPLE, this is a problem.
The program:
-- aux.h -
#include "stdlib.h"
typedef struct A A_t;
typedef struct A B_t;
struct A {
Andrew,
Dominance and reachability are two different but related things. It's trivial
to come up with a simple example to show this.
Gary
From: Andrew Pinski
Sent: Friday, October 9, 2020 8:13 PM
To: Jojo R
Cc: GCC Development
Subject: Re: How to check
Erick,
I assume that this needs to be done on all the functions since
you mention "cfun".
Gary
From: Erick Ochoa
Sent: Monday, September 14, 2020 12:10 AM
To: Gary Oblock ; gcc@gcc.gnu.org
Subject: Re: Dominance information problem
[EXTERNAL EMAIL NOTICE: This
I'm trying to do performance qualification for my structure
reorganization optimization.
I'm doing pretty straightforward stuff and I haven't at this point in
time (qualifying the optimization,) modified the program. So I'm a
little surprised this is failing. Here is the code that's failing on
ock
Cc: gcc@gcc.gnu.org
Subject: Re: A couple GIMPLE questions
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:
> First o
Cc: gcc@gcc.gnu.org
Subject: Re: A couple GIMPLE questions
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:
> First off one of the qu
First off one of the questions just me being curious but
second is quite serious. Note, this is GIMPLE coming
into my optimization and not something I've modified.
Here's the C code:
type_t *
do_comp( type_t *data, size_t len)
{
type_t *res;
type_t *x = min_of_x( data, len);
type_t *y =
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))
{
.
.
}
I noticed an extra void argument that didn't exist
gcc@gcc.gnu.org
Subject: Re: Types are confused in inlining
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
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 conversion in ‘ssa_name’
5 | main(void)
| ^
struct type_t *
d 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.
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information prot
l sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
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 chang
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 to change.) However, this seems too has its own
issues.
In one
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
numbers to be backward... but at least have I confirmed that's
what seems to
be mindful of safe email handling and proprietary information protection
practices.]
On Tue, Aug 11, 2020 at 08:27:29PM +, Gary Oblock via Gcc wrote:
> For these two dump files:
>
> exe.ltrans0.ltrans.074i.cp
>
> and
>
> exe.ltrans0.ltrans.087i.structure-reorg
>
>
Note, I'm getting close to getting my part of the structure reorganization
optimization minimally functional (my question about value range propagation
remains open since I re-enabled a couple of optimizations to bypass it.)
Therefore this is actually important for me to resolve.
I obviously
For these two dump files:
exe.ltrans0.ltrans.074i.cp
and
exe.ltrans0.ltrans.087i.structure-reorg
doesn't the ".074i." mean that this dump was created
before the ".087i." dump?
If so then why does the ".074i." show GIMPLE that was
created in the structure-reorg pass?
Thanks,
Gary
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 on some optimization (my structure reorg
optimization) generated
This problem is from my structure reorganization optimization
optimization code (simplified and cleaned to illustrate
the problem.
Here's what happening below at the high level
>From the user program:
typedef struct type type_t;
struct type {
double x;
double y;
}:
I'll be creating:
> From: Richard Biener
> Sent: Tuesday, July 28, 2020 12:07 AM
> To: Gary Oblock
> Cc: gcc@gcc.gnu.org
> Subject: Re: Gcc Digest, Vol 5, Issue 52
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
> be mindful of safe
TICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
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 ini
Almost all of the makes sense to.
I'm not sure what a conditionally initialized pointer is.
You mention VAR_DECL but I assume this is for
completeness and not something I'll run across
associated with a default def (but then again I don't
understand notion of a conditionally initialized
change those SSA name types?
Richard.
>Gary
>
>From: Richard Biener
>Sent: Friday, July 24, 2020 11:16 PM
>To: Gary Oblock ; Gary Oblock via Gcc
>; gcc@gcc.gnu.org
>Subject: Re: Problems with changing the type of an ssa name
>
>[EXTERN
: Friday, July 24, 2020 11:16 PM
To: Gary Oblock ; Gary Oblock via Gcc
; gcc@gcc.gnu.org
Subject: Re: Problems with changing the type of an ssa name
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
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:
tree pointer_rep =
make_signed_type ( TYPE_PRECISION (
Sent: Wednesday, July 22, 2020 2:32 AM
To: Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: Three issues
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Wed, Jul 22, 2020 at 12:51 A
. Please
be mindful of safe email handling and proprietary information protection
practices.]
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
.]
On Tue, 2020-07-21 at 22:49 +, 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
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 equal method for ssa_name_hasher
has a segfault because the "var" field of "a"
Regarding the other question I asked today could somebody explain to
me what the default_defs are all about. I suspect I'm doing something
wrong with regard of them. Note, I've isolated the failure in the last email
down to this bit (in red):
if (is_empty (*entry)
|| (!is_deleted (*entry)
I'm encountering a really painful error. The stack trace is below.
The code in hash-table.h is a template and it is really hyper-allergic
to instrumentation (a couple of fprintfs caused malloc to have an
internal error!) Last time I checked gbd didn't exactly play nice
with templates either.
uild_call and inlining
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
> be mindful of safe email handling and proprietary information protection
> practices.]
>
>
> Hi,
>
> On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
>> Thank y
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 relies on the control flow graph (which I'm
updating as I create new
and inlining
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
Hi,
On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
> Thank you Richard.
>
> I feel a bit dumb because I'm w
interaction between a call created by
gimple_build_call and inlining
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Wed, Jul 1, 2020 at 7:49 AM Gary Oblock via Gcc wrote:
>
&g
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 (stmt);
gcc_checking_assert (cg_edge);
Now, I've tried using the
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 something(s) in a glaringly stupid way.
Can you spot it, because everything
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) an
array of structures is being transformed into a structure of arrays.
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 to admit up front
that the comparison below ( ) is probably dicey.
84 matches
Mail list logo
