On Sat, 2006-11-04 at 15:17 -0500, Kenneth Zadeck wrote:
> ld.
>
> However, I think that before anyone starts hacking anything, we should
> come to a consensus on an overall strategy and implement something
> consistent for the entire compiler rather than attack some particular
> pass in a manne
I just tried compiling cplusplus_grammer.ii with mainline, checking
disabled, and had to stop it after 30 minutes (use to be <50 seconds on
my x86-linux box). A quick check with GDB seems to show that its
spending in inordinate amount of time in may_alias:
#0 0x0816d1ac in bitmap_ior_into (a=0x
On Fri, 2006-11-17 at 12:22 -0500, Andrew MacLeod wrote:
> I just tried compiling cplusplus_grammer.ii with mainline, checking
> disabled, and had to stop it after 30 minutes (use to be <50 seconds on
> my x86-linux box). A quick check with GDB seems to show that its
> spendin
On Fri, 2006-11-17 at 22:19 -0500, Daniel Berlin wrote:
> On 11/17/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-11-17 at 12:22 -0500, Andrew MacLeod wrote:
> > > I just tried compiling cplusplus_grammer.ii with mainline, checking
> > > disa
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
Using quick (in theory) and trusty cpgram.ii, I get:
tree PTA :1135.48 (88%) usr 5.47 (55%) sys1168.23 (85
On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
> My bootstrap/make check cycle took about 10 hours with yesterdays
> checkout (way longer than expected). A quick investigation shows C++
> compilation timed are through the roof.
>
> Using quick (in theory) and trusty c
On Fri, 2006-12-01 at 10:56 -0500, Andrew MacLeod wrote:
> On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigation shows C++
> > compilation
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigation shows C++
> > compilation
On Fri, 2006-12-01 at 11:45 -0500, Daniel Berlin wrote:
> On 12/1/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 12/1/06, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > > Hello!
> until we can deal with the register pressure (though i thought we had
> out-of-ssa changes to help with this now).
On Fri, 2006-12-01 at 15:06 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > >
> > > > Using quick (in theory) and trusty cpgram.ii, I get:
> > > &g
On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > > My bootstrap
On Mon, 2006-12-04 at 17:23 +0100, Richard Guenther wrote:
> On 12/3/06, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > This patch updates configure to require MPFR 2.2.1 as promised here:
> > http://gcc.gnu.org/ml/gcc/2006-12/msg00054.html
> >
> > Tested on sparc-sun-solaris2.10 using mpfr-2.2.1, m
I've been investigating a testsuite failure which shows up with the new
TER implementation, and it appears to be a bug in the code for
expand_builtin_memcpy.
The problem is an array slice of a string constant, which is this case
originates in gfortran.
The source code looks like:
subroutine f
On Mon, 2006-12-11 at 15:16 +0100, Steven Bosscher wrote:
> On 12/11/06, Kaz Kojima <[EMAIL PROTECTED]> wrote:
> > It seems that the first tree dump which differs before and
> > after r119711 is .099t.optimized.
>
> In that case, this is a different problem, probably caused by the new
> out-of-SSA
On Wed, 2007-01-10 at 21:13 +, Richard Sandiford wrote:
> I know Andrew replied privately, but I hope he doesn't mind me raising
> the issue on-list. I just wanted to guage the general feeling as to
> whether I'd screwed up, and whether I should have submitted the patches
> in a different way.
8, and propagated di into the
compare. insn 7 would be dead and we'd get the code the PR is looking
for :-)
Andrew
2007-03-05 Andrew MacLeod <[EMAIL PROTECTED]>
* tree-ssa-ter.c (find_replaceable_in_bb): Allow expression replacement
of same basename variables for s
On Tue, 2007-03-06 at 18:18 +0100, Paolo Bonzini wrote:
> > It would be really sweet if we propagated the 'di - 4' into insn 8, then
> > recognized that di is now the value of SI 58, and propagated di into the
> > compare. insn 7 would be dead and we'd get the code the PR is looking
> > for :-)
>
On Sun, 2007-03-04 at 20:45 -0800, Mark Mitchell wrote:
> However, I do think that it's important to eliminate some of the 139
> open P2 and P1 regressions [2], especially those P1 regressions which
> did not appear in GCC 4.1.x.
There are a handful I've been involved with which are labeled as
4.
On Mon, 2007-03-19 at 10:33 -0700, Joe Buck wrote:
> On Mon, Mar 19, 2007 at 09:27:25AM -0400, Diego Novillo wrote:
> > Manuel López-Ibáñez wrote on 03/17/07 14:28:
> >
> > > This is the project proposal that I am planning to submit to Google
> > > Summer of Code 2007. It is based on previous work
On Tue, 2007-04-10 at 00:49 -0400, Diego Novillo wrote:
> Following up on the recent discussion about GIMPLE tuples
> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
> our main ideas and implementation proposal in the attached document.
>
> This should be enough to get the im
On Tue, 2007-04-10 at 19:54 +0200, J.C. Pizarro wrote:
> Hi Diego Novillo
>
> Your "Tuple representation" of the GIMPLE instructions was:
> HEADER:
> code16 bits
> subcode 16bits
> nextword
> prevword
> bb word
> locus word
> block wor
On Tue, 2007-04-10 at 20:39 +0100, Dave Korn wrote:
> On 10 April 2007 20:02, Diego Novillo wrote:
>
> >> The obvious way to make the proposed tuples position independent would
> >> be to use array offsets rather than pointers. This has the obvious
> >> disadvantage that every access through a po
On Tue, 2007-04-10 at 16:03 -0400, Diego Novillo wrote:
> Dave Korn wrote on 04/10/07 15:39:
>
> > Reverse-traversing an array really isn't all that painful or slow!
>
> Instructions are not laid out in an array. Insertion and removal is
> done constantly. It would be very expensive to use ar
On Tue, 2007-04-10 at 15:02 -0400, Diego Novillo wrote:
> Ian Lance Taylor wrote on 04/10/07 14:13:
> > I would like us to seriously think about this approach. Most of the
> > details would be hidden by accessor macros when it comes to actual
> > coding. The question is whether we can tolerate s
What if we try a variation on this. Im not even sure how I feel about
it since its even wonkier than what you suggest.
first, create a unique GV for each type, and implement a gatherer
definition. Instead of individual VMAYDEFS for 3 variables, we have a
gatherer which assigns them all to one g
On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> In the interest of brevity, I'm just going to point out the
> problematical store from the .ifcvt dump:
>
>
> # x_16 = V_MAY_DEF ;
> # SFT.3_20 = V_MAY_DEF ;
> *D.1470_8 = D.1472_11;
>
> Which gets vectorized and appears like this in
On Fri, 2005-04-08 at 13:26, Devang Patel wrote:
> On Apr 8, 2005, at 10:08 AM, Jeffrey A Law wrote:
>
> > On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> >>> When we rescan the operands, we get a different set of V_MAY_DEFS,
> >>> specifically we lose the V_MAY_DEF for SFT.3_20.
> >>
>
On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > specifically we lose the V_MAY_DEF for SFT.3_20. Which results in
> > uses of SFT.3_20 later,
On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
>
actually, I'll jsut keep talking to myself here :-)
> > In the interest of brevity, I'm just going to point out the
> > problematical store from the .ifcvt du
On Mon, 2005-04-25 at 04:48, Zdenek Dvorak wrote:
> Hello,
>
> > I am thinking about merging stmt_ann_d into tree_statement_list_node.
> >
> > Background
> > --
> >
> > tree_statement_list_node is a linked list node defined like so
> >
> > struct tree_statement_list_node {
> > struct t
On Mon, 2005-04-25 at 11:32, Kazu Hirata wrote:
> I might need your help later as a loop optimizer expert. I just found
> yesterday that tree-ssa-loop-im.c:schedule_sm is using stmt_ann before
> a statement proper is linked to a basic block. Specifically, it
> creates a statement, attaches a stm
On Mon, 2005-04-25 at 12:00, Kazu Hirata wrote:
> Hi Andrew,
> > I believe DOM uses the routine to create a dummy expression for a store
> > which looks like a load. This load is then entered into the equivalency
> > tables such that the store of the expression also shows up as a load
> > allowing
On Mon, 2005-04-25 at 14:37, Kazu Hirata wrote:
> Hi Andrew,
>
> > well, there isnt a tree_statement_list_node right... DOM simply has an
> > expression, and we end up calling create_stmt_ann. I guess you would
> > have to create a completely detached stmt_list node for this case. what
> > are y
On Mon, 2005-04-25 at 17:55, Kazu Hirata wrote:
> Hi Andrew,
>
> > How is the get_stmt_ann (stmt) going to work from the caller of
> > create_ssa_artificial_load_stmt() when it goes to look at the operands
> > for its new "stmt"?
>
> I am going to replace that particular call to get_stmt_ann w
On Mon, 2005-04-25 at 19:01, Kazu Hirata wrote:
> Hi Andrew,
> No, I would like to remove stmt_ann_t pointer from the stmt node, but
> not yet. All I want to do in this project is to put
> tree_statement_list_node and stmt_ann_d next to each other in memory
> while doing necessary adjustments in
On Mon, 2005-04-25 at 20:32, Kazu Hirata wrote:
> Hi Adnrew,
> This looks like a better approach. How would we do your step 1? We
> have var_ann and tree_ann in addition to stmt_ann. Shall we put a
> type field at the beginning of tree_statement_list_node+stmt_ann_d so
> that an annotation node
On Wed, 2005-04-27 at 04:22, Jeffrey A Law wrote:
> On Tue, 2005-04-26 at 23:40 -0700, Zack Weinberg wrote:
> > Wasn't TER a temporary kludge that should be going away?
> When we have a tree combiner I would expect TER to disappear.
Or if tree expansion were rewritten. One of the many things still
Why is it we try to swap operands in get_expr_operands, where we are
otherwise simply parsing not modifying?
/* If it would be profitable to swap the operands, then do so to
canonicalize the statement, enabling better optimization.
By placing canonicalization of such
On Wed, 2005-05-04 at 11:07, Jeffrey A Law wrote:
> On Wed, 2005-05-04 at 10:28 -0400, Andrew MacLeod wrote:
> > Why is it we try to swap operands in get_expr_operands, where we are
> > otherwise simply parsing not modifying?
> >
> > /* If it would be profitable
Do we currently have an RTL infix printing mechanism hidden away
somewhere? I seem to vaguely recall new-ra might have had something
once upon a time... I also suspect others have fooled with it over the
years.
Is there code laying around I can snarf and work with?
Andrew
On Wed, 2005-05-18 at 09:23, Steven Bosscher wrote:
> On May 18, 2005 03:06 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
>
> > So far OK, but with ter, this becomes
> >
> > sum1 = 0;
> > sum2 = 0;
> > for (i = 0; i < n; i+=4)
> > {
> > x_1 = a[i];
> > y_1 = b[i];
> > x_2 = a[i+1];
>
On Wed, 2005-08-24 at 18:28 -0400, Daniel Berlin wrote:
> > Could someone look into this and see what they can do?
>
> You should probably ask Diego or Andrew directly whether they'd like us
> to do this in bsi_remove (which requires adding an argument) and
> remove_phi_node(ditto) so that a lot
On Wed, 2005-08-24 at 21:26 -0400, Daniel Berlin wrote:
> On Wed, 2005-08-24 at 19:19 -0400, Andrew MacLeod wrote:
> > removing a stmt doesn't mean that the def is no longer needed.
>
> That ws the goal of the extra argument, however
I noticed this after I sent the note :-
On Sat, 2005-09-17 at 14:59, Daniel Berlin wrote:
> It seems the only reason we have PHI_ARG_IMM_USE_NODE (and a struct
> ssa_use_operand_d) in a phi node argument (struct phi_arg_d) is *just*
> so we can iterate over the uses and hand back use_operand_p.
>
> I'm talking, in particular, about:
>
On Tue, 2005-10-25 at 09:36 -0400, Daniel Berlin wrote:
> On Tue, 2005-10-25 at 10:13 +0530, Ranjit Mathew wrote:
> > On 10/25/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> > > >
> > > > First off, several fields are marked "skip", though the
> > > > documents seem to strongly discourage this. For ex
It must be the season for this sort of thing :-)
I have been contemplating building a GCC register allocator from scratch
for some time. To that end, I have put together a bit of a document
given a high level overview of the various components I think would
benefit GCC, and a rough description of
On Fri, 2005-11-18 at 10:53 +0100, Giovanni Bajo wrote:
> Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> 1) Do you believe there will be sub-parts of this project which could be
> carried on succesfully and efficiently by programmers without previous RTL
> experience? IIUC, the
On Fri, 2005-11-18 at 22:18 -0800, Ian Lance Taylor wrote:
> Andrew MacLeod <[EMAIL PROTECTED]> writes:
> Secondary/tertiary reloads and reload_in/out patterns are apparently
> subsumed by the Spill Engine. Porting a target to the new framework
> is going to require providin
On Sun, 2005-11-20 at 01:37 +0100, Steven Bosscher wrote:
> On Thursday 17 November 2005 17:53, Andrew MacLeod wrote:
> > http://people.redhat.com/dnovillo/rable.pdf
>
> How are the insn annotations and caches you propose different from
> what df.c already does?
>
I don
On Tue, 2005-11-22 at 13:26 -0600, Peter Bergner wrote:
> Register Coalescing [page(s) 8]:
> * We will probably need some method for telling the coalescer
> that a particular copy (or type of copy/copies) should either
> be completely ignored (ie, do not coalesce it even if it look
On Mon, 2006-01-09 at 08:22 +0530, Ranjit Mathew wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> However, it still remains true that the code path
> I referred to is wrong and if, as you say, it can
> never be taken, it should just be removed and
> replaced with an assertion codifying w
I occasionally get a build failure in libgcc when doing a scratch build
(onx86_64-unknown-linux-gnu) , and if I simply do another make, it works
fine. I am always building with make -j16, so its never been easy to spot.
This morning, it happened to fail in such a way that I can sort of see
wh
which ends up overwriting gthr-default.h at what
turns out to be a poor time ? that sort of makes sense I guess. Im
not sure how we synchronize the parallel bits.
Andrew
so it probably is related to rerunning config.status
On 07/15/2015 10:07 AM, Andrew MacLeod wrote:
I occasionally get a build
On 07/15/2015 02:58 PM, Jeff Law wrote:
On 07/15/2015 08:33 AM, Andrew MacLeod wrote:
Maybe if gthr-default already existed (as well as config.status), the
makefile would spawn the libgcov-interface.c object builds... meanwhile
a reconfigure is going which ends up overwriting gthr-default.h
On 03/07/2016 11:33 AM, David Malcolm wrote:
So for testing specific passes, I'd much rather have an input format
for testing individual passes that:
* can be easily generated by GCC from real test cases
* ability to turn into unit tests, which implies:
* human-readable and editabl
On 03/09/2016 10:47 AM, Richard Biener wrote:
On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod wrote:
On 03/07/2016 11:33 AM, David Malcolm wrote:
So for testing specific passes, I'd much rather have an input format
for testing individual passes that:
* can be easily generated b
On 09/14/2016 09:33 AM, Richard Biener wrote:
On Wed, Sep 14, 2016 at 3:25 PM, Aldy Hernandez wrote:
Hi folks. I'm working on better range information with Macleod, and I've
been playing with folding arbitrary range expressions, which I expect fold()
to ahem...fold.
I'm surprised that even se
On 09/14/2016 03:29 PM, Richard Biener wrote:
On September 14, 2016 6:39:14 PM GMT+02:00, Jeff Law wrote:
On 09/14/2016 08:08 AM, Andrew MacLeod wrote:
range generator understands, we just thought it would be handy to
leverage the folder during the proof of concept stage.
It's also
On 06/18/2014 12:59 PM, Basile Starynkevitch wrote:
Hello All,
The following code:
#include
struct s1_st {
char* i_name;
struct s1_st* i_foo;
};
void clear_s1 (struct s1_st*s)
{
__atomic_store(s->i_name, NULL, __ATOMIC_SEQ_CST);
}
gives an ICE when c
On 07/09/2014 02:17 AM, Tobias Burnus wrote:
Hello all,
I am trying to use BUILT_IN_ATOMIC_..., but it does not quite work. I
am calling them as:
tmp = builtin_decl_explicit (BUILT_IN_ATOMIC_LOAD_4);
tmp = build_call_expr_loc (input_location, tmp, 2, atom.expr, ...
That gives the followi
On 08/05/2014 10:21 AM, Prathamesh Kulkarni wrote:
Hi,
I have written notes on "GCC re-architecture BOF"
presented at the Cauldron. I would be grateful if you would
review it for me.
Seems to cover the core parts well... all subject to change as we go
tho :-)
initial focus wlll be the ty
During the re-architecture session at Cauldron, I mentioned the
possibility of introducing a plugin-headers.h.
This would be a file which plugins could use which would protect them
somewhat from header file restructuring. The idea is that it includes
all the common things plugins need, (like
On 09/15/2014 02:18 PM, Andrew MacLeod wrote:
During the re-architecture session at Cauldron, I mentioned the
possibility of introducing a plugin-headers.h.
This would be a file which plugins could use which would protect them
somewhat from header file restructuring. The idea is that it
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
On Sat, 2014-11-0
On 11/13/2014 09:34 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 3:24 PM, Andrew MacLeod wrote:
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm
wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks like it was part of the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
decl_attributes() can be passed a tree node which is
On 11/18/2014 09:40 AM, Jason Merrill wrote:
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks like it was part of the fix for
https
On 11/18/2014 09:52 AM, Andrew MacLeod wrote:
On 11/18/2014 09:40 AM, Jason Merrill wrote:
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It
On 11/18/2014 01:36 PM, Jeff Law wrote:
On 11/18/14 09:30, Andrew MacLeod wrote:
I tried doing the if before chaning to TREE_TYPE... absolutely no
effect on the testsuite or anything else :-)
What do you think, should I check this in? What is there is clearly
incorrect.we could also
On 03/26/2015 04:02 PM, Jason Merrill wrote:
The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says,
---
typedef char B3[3];
_Atomic B3 obj2;
An object will be promoted up to the next lock-free size in order to
enable lock free operations, as long as it isn't already a do
On 04/20/2015 09:18 AM, Richard Biener wrote:
On Mon, Apr 20, 2015 at 3:02 PM, Martin Jambor wrote:
Hi,
because I really dislike the hassle our (almost) flattened header
files cause quite often, I have made a very simple experiment to find
out how the header files really depend on each other.
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4/16 extraction, so last
night I checked out a fresh trunk, built it, ran make check... then
removed the build directory, re-built it from scratch again. make
check.. and get a bunch of different re
On 04/22/2015 08:19 AM, Jakub Jelinek wrote:
On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4/16 extraction, so last night I
checked out a fresh trunk, built it, ran make check
On 04/22/2015 08:33 AM, Jeff Law wrote:
On 04/22/2015 06:28 AM, Andrew MacLeod wrote:
On 04/22/2015 08:19 AM, Jakub Jelinek wrote:
On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4
What is valid in a switch statement for type compatibility?
I would have expected it to follow what appears to be the gimple
"standard" of allowing types that pass the
"useless_type_convserion_p()" test.
I am doing some switch analysis and an triggering a failure in ADA when
the gimple_sw
On 10/29/18 1:30 PM, Richard Biener wrote:
On October 29, 2018 6:20:25 PM GMT+01:00, Andrew MacLeod
wrote:
What is valid in a switch statement for type compatibility?
I would have expected it to follow what appears to be the gimple
"standard" of allowing types tha
On 4/1/19 12:49 PM, nick wrote:
On 2019-04-01 4:21 a.m., Martin Liška wrote:
On 3/29/19 11:29 PM, nick wrote:
Greetings all,
Not sure why this exists still as tree-eh.h is including in tree-eh.c which
defines this header
as used for this FIXME:
#include "tree-pass.h" /* FIXME: onl
On 4/1/19 5:17 PM, nick wrote:
On 2019-04-01 1:54 p.m., Andrew MacLeod wrote:
#include "tree-flow.h"
#include "cgraph.h"
#include "timevar.h"
#include "hashtab.h"
#include "flags.h"
#include "function.h"
#include "ggc.h"
#i
On 5/7/19 2:40 PM, nick wrote:
Andrew,
I read through your notes briefly on this issue and if you want help I'm game
for it.
I assuming it's fixed not through as the gcc projects pages tend to me out of
date in
my experience.
Nick
Yeah, very old project and not really on the radar any more :
*This note will talk about the 4 major components of the prototype and
explain how they work together. I will be fairly light on detail just
to give an overview, we can delve into whatever details are needed.
- Range-ops : Range operations at the statement level
- GORI - Generates Outgoing Ran
Now that stage 1 has reopened, I’d like to reopen a discussion about the
technology and experiences we have from the Ranger project I brought up
last year. https://gcc.gnu.org/ml/gcc/2018-05/msg00288.html . (The
original wiki pages are now out of date, and I will work on updating
them soon.)
There is a functioning prototype in branch “ssa-range” which is a proof
of concept that the approach is functional as well as quick, and can be
used to answer questions which come up regarding what it can and can’t
do. Our last merge was on April 13th, so it's fairly up to date.
We have imple
We have done extensive performance analysis to help address concerns
about the nature of an on-demand model. LLVM made an attempt at
something similar, but suffered from significant performance issues
they could not solve with their approach. This approach is not the same,
and we have seen no
A primary goal of this approach is to try to pull the various aspects of
VRP apart and make them individually viable so they can be used at
appropriate places as needed. The various components of VRP were
identified as:
- Ranges
- Relational queries
- Equivalencies
- Bitmask tr
On 5/23/19 8:55 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:28 AM Andrew MacLeod wrote:
2 * GORI
The second component is the “Generates Outgoing Range Info” engine.
This is a basic-block oriented component which determines what ssa-names
have ranges created on outgoing
On 5/23/19 9:10 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
This aspect of symbolics would be handled by a relational/equivalence
processing engine that would be follow on work. Using the same basic
model as ranges, each tree code is taught to understand
On 5/23/19 9:29 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
All times are with a release configured compiler. Out of the 242 files,
pretty much across the board in all 4 sets of figures, RVRP was faster
in about 90% of the cases, and slower in the other 10
On 5/23/19 10:07 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod wrote:
This aspect of all calculations being driven from the opcode and
combined generically without special casing at a higher level is both
very powerful and less prone to produce errors. Our initial
On 5/24/19 5:36 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 12:27 AM Eric Botcazou wrote:
While I agree that symbolic ranges are a complication and that most
cases it currently handles are not "value-range" things I do not agree
with the idea that we can simply remove handling them and de
On 5/27/19 9:02 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote:
The above suggests that iff this is done at all it is not in GORI because
those are not conditional stmts or ranges from feeding those. The
machinery doing the use-def walking from stmt context
On 5/29/19 9:11 AM, Richard Biener wrote:
On Tue, May 28, 2019 at 4:41 PM Jeff Law wrote:
This aspect of symbolics would be handled by a relational/equivalence
processing engine that would be follow on work. Using the same basic
model as ranges, each tree code is taught to understand the rel
On 5/29/19 7:15 AM, Richard Biener wrote:
On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote:
On 5/27/19 9:02 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote:
The above suggests that iff this is done at all it is not in GORI because
those are not conditional
On 5/31/19 2:16 PM, Jeff Law wrote:
On 5/31/19 9:40 AM, Andrew MacLeod wrote:
On 5/29/19 7:15 AM, Richard Biener wrote:
On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod
wrote:
On 5/27/19 9:02 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod
wrote:
The above suggests
On 5/31/19 6:00 PM, Jeff Law wrote:
On 5/31/19 2:26 PM, Andrew MacLeod wrote:
On 5/31/19 2:16 PM, Jeff Law wrote:
On 5/31/19 9:40 AM, Andrew MacLeod wrote:
stmt-level tracking of ranges are sometimes important. This is
something the machinery cannot provide - correct? At least not
On 6/4/19 11:26 AM, Richard Biener wrote:
On Fri, May 31, 2019 at 5:40 PM Andrew MacLeod wrote:
On 5/29/19 7:15 AM, Richard Biener wrote:
On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote:
On 5/27/19 9:02 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote
On 6/4/19 11:37 AM, Richard Biener wrote:
On Tue, Jun 4, 2019 at 5:26 PM Richard Biener
wrote:
But you still have a reference to the range in evry BB dominated by the
definition?
Btw, I was thinking of
unsigned char foo(long);
void baz(unsigned char c)
{
try{
long i = c;
i +
On 6/4/19 1:07 PM, Richard Biener wrote:
On June 4, 2019 6:50:07 PM GMT+02:00, Andrew MacLeod
wrote:
On 6/4/19 11:37 AM, Richard Biener wrote:
where the single(!) query of the range of i on the alloca call
will populate N BBs caches with the Nth having ranges for
all SSA defs of i running
On 6/4/19 4:21 PM, Marc Glisse wrote:
On Tue, 4 Jun 2019, Martin Sebor wrote:
On 5/31/19 9:40 AM, Andrew MacLeod wrote:
On 5/29/19 7:15 AM, Richard Biener wrote:
On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod
wrote:
On 5/27/19 9:02 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 5:50 PM
After the various discussions, I've evaluated how I think everything can
fit together, so this is my proposal for integration with trunk.
The complete Ranger prototype consists of 5 major components, one of
which is missing/un-implemented as yet :-)
1 - irange - This is the non-symboli
On 6/6/19 6:20 AM, Martin Liška wrote:
Hi.
The code is dead:
757 char *
758 get_lsm_tmp_name (tree ref, unsigned n, const char *suffix)
759 {
760 char ns[2];
761
762 lsm_tmp_name_length = 0;
763 gen_lsm_tmp_name (ref);
764 lsm_tmp_name_add ("_lsm");
1 - 100 of 254 matches
Mail list logo
