Hi,
On Thu, 22 Nov 2012, Lawrence Crowl wrote:
I have found that tree-flow.h implements iteration over htab_t,
while there is no current facility to do that with hash_table.
Unfortunately, the specific form does not match the standard C++
approach to iterators. We have several choices.
Hi,
On Tue, 20 Nov 2012, Lawrence Crowl wrote:
On 11/19/12, Diego Novillo dnovi...@google.com wrote:
On Nov 19, 2012 Michael Matz m...@suse.de wrote:
So, yes, the larger layouting should be determined by name of the
dump function. A flag argument might look nice from an interface
Hi,
On Tue, 20 Nov 2012, Martin Jambor wrote:
+++ gcc/ipa-cp.c2009-09-29 15:29:05.0 +0200
@@ -298,7 +298,7 @@ ipcp_lattice_from_jfunc (struct ipa_node
return;
cst = caller_lat-constant;
- if (jfunc-value.pass_through.operation != NOP_EXPR)
+ if (!
Hi,
On Tue, 20 Nov 2012, Steven Bosscher wrote:
On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote:
Richi, ping?
Just guessing... isn't he simply out on Honeymoon?
Yes, he'll be back next week.
Ciao,
Michael.
Hi,
On Mon, 19 Nov 2012, Martin Jambor wrote:
Well, this is what I was actually afraid of. If things like generic
or tree dump of a tree value is selected by new TDF_ flags, then you
are in danger of just replacing current mess in function names by a
mess of constants. I'd much rather have
Hi,
On Fri, 16 Nov 2012, Lawrence Crowl wrote:
I think the field htab_t original_pddrs in struct scop in
graphite-poly.h is unused.
Seems I overlooked it during my post-isl cleanups. Yes, remove it.
Ciao,
Michael.
Hi,
On Fri, 16 Nov 2012, Andrew Pinski wrote:
Ah, yes. This one was amusing. When we were drafting the proposal,
Lawrence kept wondering what this NOP_EXPR thing is. I've been
suffering this name for so long, that it no longer irritates me.
Had it been named CAST_EXPR, or even
Hi,
On Mon, 19 Nov 2012, Steven Bosscher wrote:
On Mon, Nov 19, 2012 at 2:10 PM, Michael Matz wrote:
Hi,
On Fri, 16 Nov 2012, Andrew Pinski wrote:
Ah, yes. This one was amusing. When we were drafting the proposal,
Lawrence kept wondering what this NOP_EXPR thing is. I've been
Hi,
On Thu, 15 Nov 2012, Lawrence Crowl wrote:
They allow us to use the same name for the same actions in two
different contexts. In particular, distinguishing between statement
construction in SSA and non-SSA.
I don't see the difference, and I don't see where you need context data to
Hi,
On Fri, 16 Nov 2012, Diego Novillo wrote:
I think consistency should trump brevity here, so also add a tree code for
the converter, i.e.
ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a);
Ah, yes. This one was amusing. When we were drafting the proposal,
Lawrence kept wondering
Hi Lawrence,
On Wed, 14 Nov 2012, Lawrence Crowl wrote:
Diego and I seek your comments on the following (loose) proposal.
In principle I agree with the goal, I'm not sure I like the specific way
yet, and even if I do I have some suggestions:
We will add a set of helper classes to be used as
Hi,
On Thu, 15 Nov 2012, Gabriel Dos Reis wrote:
On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz m...@suse.de wrote:
[...]
The method name should imply the action, e.g. 'add_stmt' or append_stmt
or the like.
strongly agreed.
[...]
All in all I think we can severely improve
Hi,
On Thu, 15 Nov 2012, Steven Bosscher wrote:
Current HEAD fails build when --enable-languages=c, i.e. C++ is not
being built. Attached patch fixes this.
Eh???
Uhh???
Isn't C++ always built, because gcc itself requires it?
Without bootstrapping it doesn't, no.
Ciao,
Michael.
Hi,
On Wed, 14 Nov 2012, Paulo Matos wrote:
There's a function in lto-streamer-out.c which determines if a tree is
streamable.
This is lto_is_streamable? I have a LANG_TYPE that I want to stream and
adding to that function:
#ifdef TARGET_MYPORT
if (code == LANG_TYPE)
return true;
Hi,
On Tue, 30 Oct 2012, Richard Biener wrote:
On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen de...@google.com wrote:
And tree expressions don't have TREE_BLOCK before gimple-low either.
So IMNSHO it is gimple-low.c that should set TREE_BLOCK of all the gimple
stmts as well as all expression
Hi,
On Sat, 27 Oct 2012, Ian Lance Taylor wrote:
On Sat, Oct 27, 2012 at 1:45 PM, Caroline Tice cmt...@google.com wrote:
Ian Tayler (in private communication) asked that I get the part of the
build log that shows the .so and .a files being built and send it to
the list. Here it is.
I
Hi,
On Fri, 26 Oct 2012, Dehao Chen wrote:
1. abandon the changes in cfgexpand.c
Well, you merely moved the bogus code to gimple-low.c. It is bogus
because you unconditionally overwrite TREE_BLOCK of all operands (and all
operands operands) with the statements block. I assume the unit-test
Hi,
On Mon, 29 Oct 2012, Richard Biener wrote:
Well, you merely moved the bogus code to gimple-low.c. It is bogus
because you unconditionally overwrite TREE_BLOCK of all operands (and all
operands operands) with the statements block. I assume the unit-test you
added shows the problem
Hi,
On Mon, 29 Oct 2012, Dehao Chen wrote:
On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz m...@suse.de wrote:
Hi,
On Mon, 29 Oct 2012, Richard Biener wrote:
Well, you merely moved the bogus code to gimple-low.c. It is bogus
because you unconditionally overwrite TREE_BLOCK of all
Hi,
On Thu, 25 Oct 2012, Dehao Chen wrote:
* cfgexpand.c (set_expr_location_r): New callback function.
(gimple_assign_rhs_to_tree): Walk the expr recursively.
(expand_call_stmt): Likewise.
(expand_gimple_stmt_1): Likewise.
This cannot be right. You're going to propagate a toplevel
Hi,
On Tue, 23 Oct 2012, Richard Biener wrote:
... for this. We should never produce UNDEFINED when the input
wasn't
UNDEFINED already.
Why?
Because doing so _always_ means an invalid lattice transition. UNDEFINED
is TOP, anything not UNDEFINED is not TOP. So
Hi,
On Tue, 23 Oct 2012, Richard Biener wrote:
So, one question, are you claiming that a VRP worker like this:
VR derive_new_range_from_operation (VR a, VR b)
is _ever_ allowed to return UNDEFINED when a or b is something else than
UNDEFINED? You seem to claim so AFAIU, but at
Hi,
On Tue, 11 Sep 2012, Michael Matz wrote:
the operands cache is ugly. This patch removes it at least for the def
operands, saving three pointers for roughly each normal statement (the
pointer in gsbase, and two pointers from def_optype_d). This is
relatively easy to do, because all
Hi,
On Mon, 22 Oct 2012, Richard Biener wrote:
This fixes PR55011, it seems nothing checks for invalid lattice
transitions in VRP,
That makes sense, because the individual parts of VRP that produce new
ranges are supposed to not generate invalid transitions. So if anything
such checking
Hi,
On Mon, 22 Oct 2012, Richard Biener wrote:
On Mon, 22 Oct 2012, Michael Matz wrote:
Hi,
On Mon, 22 Oct 2012, Richard Biener wrote:
This fixes PR55011, it seems nothing checks for invalid lattice
transitions in VRP,
That makes sense, because the individual parts
Hi,
On Sat, 13 Oct 2012, Lawrence Crowl wrote:
I have no problem in always returning a status change, if you are OK
with that.
I am ok with that.
There is some rationale for being concerned about performance, as the
checking routines need to read memory locations that they
Hi,
On Thu, 27 Sep 2012, Lawrence Crowl wrote:
template typename T
struct D : BT
{
typedef typename BT::E E; // element_type
E getme (int index);
}
Inside that struct, lets say we have a field of type E. Do we name
it F or f?
IMHO only for types, not for any other decls.
Hi,
On Wed, 26 Sep 2012, Lawrence Crowl wrote:
A lower-case type name indicates to me a non-changing type,
i.e. nothing that depends on a template. In C we only had
such types so we used lower-case names everywhere. With C++
and templates I think we should start using upper case for
Hi,
On Tue, 25 Sep 2012, Lawrence Crowl wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T
Hi,
On Thu, 20 Sep 2012, Dehao Chen wrote:
4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 Failed one
regression test in libgomp (I didn't know that there are regression
tests for libraries before...) This error should be a bug exposed by
this patch. I'll try to provide a patch as
Hi,
On Wed, 19 Sep 2012, Richard Guenther wrote:
Just write:
varpool_node *vnode;
if ((vnode = node-try_variable ()) vnode-finalized)
varpool_analyze_node (vnode);
This has been the standard style for the past 2 decades and trading it for
cascading if's is really a bad
Hi,
On Wed, 19 Sep 2012, Lawrence Crowl wrote:
On 9/19/12, Eric Botcazou ebotca...@adacore.com wrote:
The language syntax would bind the conditional into the
intializer, as in
if (varpool_node *vnode = (node-try_variable ()
vnode-finalized))
Hi,
On Wed, 19 Sep 2012, Martin Jambor wrote:
(The patch does not introduce any of the asserts Michael's patch had
because, as far as I my grep told me, IS_UNKNOWN_LOCATION is not in
trunk yet and I suppose the pre-approval does not cover introducing
things like that.)
Dehaos patch
Hi,
On Tue, 11 Sep 2012, Lawrence Crowl wrote:
change
node-symbol.whatever
to
node-ref_symbol().whatever
Please don't uglify the compiler with this. If GTY deficiencies force you
to do that, then hold off on it until GTY doesn't force you anymore.
Ciao,
Michael.
Hi,
On Wed, 12 Sep 2012, Richard Guenther wrote:
This will actually not work correctly in some cases. The problem is,
if the prevailing decl is already part of another chain (say in
another block_var list) you would break the current chain. Hence
block vars need special handling in
Hi,
On Wed, 12 Sep 2012, Richard Guenther wrote:
It hides a bug. If we replace anything in BLOCK_VARS then the risk
is that you generate an infinite chain in some BLOCK_VARS list and
thus get infinite loops somewhere in the compiler.
That's what I said for using SET_PREVAIL. But
Hi,
On Wed, 12 Sep 2012, Michael Matz wrote:
Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
local TYPE_DECLs). Those are supposed to be in the local function
sections only where no fixup for prevailing decls happens.
That's true, something is fishy with the patch
Hi,
On Mon, 10 Sep 2012, Gabriel Dos Reis wrote:
You could also do this with an explicit pointer-to-context-struct
parameter that's passed around (and that version of the patch I
posted), but the class-based approached seems nicer to me.
Are we talking about encapsulation or looking
Hi,
On Tue, 11 Sep 2012, Richard Guenther wrote:
+++ gcc/lto/lto.c (working copy)
@@ -1559,8 +1559,6 @@ lto_fixup_prevailing_decls (tree t)
{
enum tree_code code = TREE_CODE (t);
LTO_NO_PREVAIL (TREE_TYPE (t));
- if (CODE_CONTAINS_STRUCT (code, TS_COMMON))
-
Hi,
the operands cache is ugly. This patch removes it at least for the def
operands, saving three pointers for roughly each normal statement (the
pointer in gsbase, and two pointers from def_optype_d). This is
relatively easy to do, because all statements except ASMs have at most one
def
Hi,
On Tue, 11 Sep 2012, Dehao Chen wrote:
Looks like we have two choices:
1. Stream out block info, and use LTO_SET_PREVAIL for TREE_CHAIN(t)
This will actually not work correctly in some cases. The problem is, if
the prevailing decl is already part of another chain (say in another
Hi,
On Mon, 10 Sep 2012, Richard Guenther wrote:
Thoughts?
Micha was also working on the proposed introspection API, I blame him
for not posting anything about this despite it's being ready since a
few months...
He. I didn't yet come to make the changes about operand inspectors since
Hi David,
On Mon, 10 Sep 2012, David Malcolm wrote:
Is it possible for you to post your work-in-progress code somewhere?
Attached.
I know that you don't feel it's ready for committing, but I would find
it helpful - I'm interested in understanding the general approach,
rather than seeing
Hi,
On Mon, 3 Sep 2012, Richard Guenther wrote:
Comments welcome,
No comments? Then I'll drop this idea for 4.8.
Hey, don't discard my face2face comments :) Regarding -Og it's about
time, I like it, and your implementation is a start. The pass list (e.g.
if to include LIM or not, or
Hi,
as the bug report tells us one speed problem is loop header copying, in
particular the update_ssa call that is done for each and every copied loop
header but touches all blocks in a function.
Now, one idea was to use an optimized update_ssa that works only on the
relevant subset of blocks
Hi,
On Wed, 29 Aug 2012, Ian Lance Taylor wrote:
Does this seem like something we could usefully add to GCC? Does
anybody see any big problems with it?
Does it work without unwind tables? I suspect it doesn't as it's using
libgccs unwinder, so that would be a problem if we were to use it
Hi,
On Tue, 28 Aug 2012, Ian Lance Taylor wrote:
Or do we have a rule than any file using C++ specific feature should
be renamed from *.c to *.cc at the moment the C++ feature goes inside?
We do not have such a rule and I would not recommend it. I think we
should rename all the files
Hi,
On Fri, 24 Aug 2012, Diego Novillo wrote:
void foo (int bar) __attribute__((add_location_pack));
that directs GNU C++ to add a __Gcc_call_location_pack typed
argument at each call site (properly constructed of course)?
I really like this idea.
Couldn't we make it even more
Hi,
On Thu, 16 Aug 2012, Simon Baldwin wrote:
Thanks for the note.
To make things more concrete I've appended a prototype patch below. I
don't know if any other languages are affected, but if they are this
patch should extend reasonably well to cover those also. Does anyone
have
Hi,
On Thu, 16 Aug 2012, Richard Guenther wrote:
If dumping a statement needs the containing function then we need to
either pass that down, provide a way to get from statement to function,
or stop requiring the function. Making the hash global is choice three
(deallocating the hash
Hi,
On Wed, 15 Aug 2012, Steven Bosscher wrote:
Please convince me that this :
+/* Return the outermost superloop LOOP of USE_LOOP that is a superloop of
+ both DEF_LOOP and USE_LOOP. */
+static inline struct loop *
+find_sibling_superloop (struct loop *use_loop, struct loop *def_loop)
+{
+
Hi,
On Thu, 16 Aug 2012, Diego Novillo wrote:
I like this approach, particularly since it would be used in contexts
where there is no simpler scheme. I'm not crazy about overloading
unused fields, but it's fine if we wrap it around a special accessor. I
suppose we could also make
Hi,
On Thu, 16 Aug 2012, Steven Bosscher wrote:
2. In find_sibling_superloop the first step is to align the loop depth:
...
3. Now that USE_LOOP and DEF_LOOP are at the same nesting depth,
Ah, that's the crucial point I missed, the while loops starts out with
loops at the same depth; yes
Hi,
On Wed, 15 Aug 2012, Richard Guenther wrote:
Prototype below - fire away on bikeshedding names.
Make it mirror the preprocessor names that people are used to, and do away
with the _loc_: __builtin_FILE, __builtin_FUNCTION, __builtin_LINE.
Ciao,
Michael.
Hi,
On Wed, 15 Aug 2012, Richard Guenther wrote:
Like the following, only the coverage.c use is converted. I've never
seen template function arguments anywhere and having to repeat them all
over the place is really really ugly (yes, even if only in the
implementation).
This goes with
Hi,
On Wed, 15 Aug 2012, Jan Kratochvil wrote:
It is a needless violation of C++ resolving rules.
It's not needless as the examples here show. gdb is about helping people
debug their stuff, not about language lawyering.
There are various easy way how to get it working (in .gdbinit or
Hi,
On Thu, 9 Aug 2012, Mike Stump wrote:
Ah. For simple objects like double_int I prefer to have either all
ops mutating or all ops non-mutating.
wide_int, which replaces double_int for int types, is always
non-mutating, by value interface. In C++, it will be const input
Hi,
On Thu, 9 Aug 2012, Mike Stump wrote:
On Aug 9, 2012, at 8:19 AM, Michael Matz wrote:
Hmm. And maintaining a cache is faster than
passing/returning/manipulating two registers?
For the most part, we merely mirror existing code, check out
lookup_const_double and immed_double_const
Hi,
as Steven noted in the bug report one reason of the slowness are the
myriads of calls to bitmap_set_bit, resulting from the clique generation
at the start of basic blocks. Can be sped up by using bitmap_ior. He
implemented upper triangular form for the conflict bitmap, but I couldn't
Hi,
On Fri, 3 Aug 2012, Richard Guenther wrote:
2012-08-03 Richard Guenther rguent...@suse.de
* tree.h (SSA_NAME_IS_VIRTUAL_OPERAND): New predicate.
(SSA_NAME_HAS_PARM_OR_RESULT_DECL): Likewise.
(SSA_NAME_HAS_RESULT_DECL): Likewise.
(SSA_NAME_HAS_PARM_DECL):
Hi,
this tidies ssa liveness calculation a bit (related to out-of-ssa). In
particular it doesn't make use of var annotations to compress the index
space from partitions to base variable indices anymore, but instead a
hashmap built on the fly when we need it. The basevars itself actually
Hi,
this removes the last member of var_ann_d, a bit used only locally in
remove_unused_locals, so we can as well just use a bitmap. (The funny
renaming of the member I had to do because gengtype doesn't like empty
structs, the whole thing will be removed momentarily with the third
patch).
Hi,
On Wed, 1 Aug 2012, Michael Matz wrote:
The only remaining semantic of var_ann now is if it's non-zero it's a
non-global variable that was put into referenced_vars.
And that's removed in this patch. Most of the time it's not very
interesting to know if a variable was put in referenced
Hi,
On Wed, 1 Aug 2012, Richard Guenther wrote:
Ok. Would be nice to now unify global and local var handling with a
single bitmap.
Yeah, wanted to do that as follow-up. Namely like so. Regstrapping on
x86_64-linux in progress on top of your remove-referenced-vars patches.
Okay for
Hi,
On Mon, 30 Jul 2012, Richard Guenther wrote:
This makes into-SSA no longer rely on variable annotations and instead
uses on-the-side information local to into/update-SSA. Lookups can
probably be avoided in some places if we pass around the auxiliar
information instead of looking it up
Hi,
On Wed, 11 Jul 2012, Ian Lance Taylor wrote:
We will modify g++ to support a type attribute indicating the version of
the type, as a string. This type attribute will be inherited by any
other type that uses it, as a class/struct member or via inheritance.
Type attributes will be
Hi,
On Wed, 4 Jul 2012, Steven Bosscher wrote:
On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Any suggestions how to fix this? Should tail merging detect
__builtin_unreachable and not merge such block?
That seems to be the most straight-forward thing to do. I
Hi,
On Thu, 5 Jul 2012, Richard Guenther wrote:
On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand uweig...@de.ibm.com
wrote:
Any suggestions how to fix this? Should tail merging detect
__builtin_unreachable and not merge such block?
That seems to be the most straight-forward thing
Hi,
On Thu, 5 Jul 2012, Tom de Vries wrote:
The asserts allow the return result to be optimized, but not the cfg
conditions.
AFAIU, we can insert the asserts earlier. F.i., we can insert
aD.1711_6 = ASSERT_EXPR aD.1711_1(D), aD.1711_1(D) 0
before the GIMPLE_COND in bb2.
Nope. That
Hi,
On Wed, 4 Jul 2012, Richard Guenther wrote:
[... mangling change ...]
That would not address the issue of interoperability of a C++03 library
with a C++11 program or vice versa if they are using any of the changed
interfaces for interoperability. Passing pointers to such objects
On Wed, 4 Jul 2012, Michael Matz wrote:
It will by the way not break unnoticed: interfaces using the problematic
types would be mangled differently, and hence c++98 code would silently
... would _not_ silently ...
be resolved to a c++11 variant expecting a different layout.
Hi,
On Mon, 2 Jul 2012, Jeff Law wrote:
On 07/02/2012 11:53 AM, Paolo Carlini wrote:
I also want to mention (I don't think somebody did already in the
thread) that at some point, with Jason too, we discussed the idea of
adding to each binary a marker about the ABI version which then
Hi,
On Mon, 2 Jul 2012, Mike Stump wrote:
On May 26, 2012, at 8:03 PM, Michael Matz wrote:
---
PR middle-end/38474
* cfgexpand.c (struct stack_var): Add slot_type member.
(add_stack_var): Initialize it.
(add_alias_set_conflicts): Remove
Hi,
On Mon, 2 Jul 2012, Tobias Grosser wrote:
Yeah. If my above understanding is correct the path is clear.
I believe it is.
It somewhat works. It has problems in those cases where there are
dependencies between different input dimensions in the scattering, which
happens for
Hi Tobi,
On Fri, 29 Jun 2012, Tobias Grosser wrote:
+static isl_constraint *
+build_linearized_memory_access (isl_map *map, poly_dr_p pdr)
+{
+}
The function itself looks correct. However, I would personally have returned
an isl_map instead of an isl_constraint.
As you noticed I
Hi,
so, to make progress on the graphite front we want to get rid of the ppl
dependency. We start from Tobis move-to-isl-and-isl-scheduler branch at
github, merged current trunk into that (see also Richis mails about
cloog/isl configury), and add ISL implementations of the essential parts
Hi,
On Fri, 22 Jun 2012, Tobias Grosser wrote:
There are two areas that do not yet have an isl counterpart. The
openscop import/export and the loop interchange heuristic. I think you
can safely crop the openscop import/export, as it is currently unused
and can later be added back if
Hi,
On Wed, 20 Jun 2012, Richard Guenther wrote:
Hmm? The original expression is an address, I have to build a MEM_REF
out of that, and the is_gimple_mem_ref_addr() just checked that that
very address (after going through fold) is not acceptable as MEM_REF
operand. So how could I
Hi,
On Thu, 21 Jun 2012, Richard Guenther wrote:
The flag is not restricted to the C++ compiler and applies to all
automatic variables.
The use of that flag in the gimplifier (-in_cleanup_expr) makes it
actually c++ specific.
Also even with this flag there is no guarantee we cannot figure
Hi,
On Tue, 19 Jun 2012, Richard Guenther wrote:
The MEM_REF is acceptable to the tree oracle and it can extract
points-to information from it.
Thus for simplicity unconditionally building the above is the best.
But it doesn't work, as refs_may_alias_p_1 only accepts certain operands
in
Hi,
On Wed, 20 Jun 2012, Richard Guenther wrote:
+ exp = fold_build2 (MEM_REF,
+ build_array_type (char_type_node,
+ build_range_type (sizetype,
+ size_one_node,
len)),
+
Hi,
On Tue, 19 Jun 2012, Richard Guenther wrote:
So, we have to build a memref always and rewrite its type to one
representing the real size. Note that TYPE_MAX_VALUE may be NULL, so we
don't need to check for 'len' being null or not.
This fixes the C testcase (don't know about fma
Hi,
On Mon, 18 Jun 2012, Gabriel Dos Reis wrote:
Jeff, please note that the path that Michael took from what was said
ealier (in particular the quote he provided in his message) and the
conclusion of enthusiasm for soname bump is still a mystery.
The quoted part suggested switching
Hi,
On Sat, 16 Jun 2012, Jonathan Wakely wrote:
On 16 June 2012 12:01, Arch hvv wrote:
Have anybody inspected it? Is GPL violated in this case or not (e.g.
do they provide all patches they've made to gcc)?
If it's based on llvm-gcc then it only uses GCC as the front-end so
there may be
Hi,
On Fri, 15 Jun 2012, Gabriel Dos Reis wrote:
On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight f...@fuhm.net wrote:
IMO, at the /very least/, libstdc++ should go ahead and change std::string
to be the new implementation. Once std::string is ABI-incompatible between
the modes, there's
Hi,
On Thu, 14 Jun 2012, Richard Guenther wrote:
Restarted regstrapping the thing on x86_64 again. Okay if that
passes?
Ok.
But I wonder how the symtab cannot be ready when we gimplify - after
all we gimplify only from after cgraph_finalize_compilation_unit ...
Ready may have been
Hi,
On Wed, 6 Jun 2012, Richard Guenther wrote:
Regstrapped this patch (all languages+Ada) on x86_64-linux, with and
without the above scheduler hacks, no regressions (without the
scheduler hacks).
The n_temp_slots_in_use part is ok.
The rest is also a good idea, and indeed the
Hi,
[Honza, for you a question below]
On Wed, 13 Jun 2012, Richard Guenther wrote:
Was a non-implemented optimization. If the compound literal value
isn't used as lvalue and doesn't have its address taken (and generally
fits the current predicate) we can as well subst it in place
Hi,
On Thu, 14 Jun 2012, Jan Hubicka wrote:
if (!from_decl
...
|| (symtab_get_node (from_decl)-symbol.in_other_partition))
return true;
in can_refer_decl_in_current_unit_p. Honza: I don't understand this
particular condition. If we have a from_decl
Hi,
On Thu, 14 Jun 2012, Michael Matz wrote:
In any case, this patch is currently in regstrapping on x86-64. Okay if
it passes (modulo changes for the above symtab_get_node() issue)?
After discussion with Honza, consider the patch changed like so:
if (!from_decl
|| TREE_CODE
Hi,
On Tue, 12 Jun 2012, Richard Guenther wrote:
Ok, I see the C frontend hands us this as
return VEC_PERM_EXPR a , b , Unknown tree: compound_literal_expr
v4si D.1712 = { 0, 4, 1, 5 }; ;
and gimplification in some way fails to gimplify it to { 0, 4, 1, 5 }.
Was a
Hi,
I haven't yet checked in my patch from last week about not creating
alias-set conflicts for stack slot sharing mostly due to the caveat I
mentioned. Namely that the RTL disambiguator still uses path-based means
(which belong to type-based aliasing) even in the write_dependence tests.
Hi,
On Tue, 29 May 2012, Richard Guenther wrote:
[... patch about making conflict handling for stack slot sharing
faster...]
The volatile handling is very odd - the objects_must_conflict_p code
basically says that two volatile vars may always share stack slots?!
What's the reasoning
Hi,
On Thu, 31 May 2012, Richard Guenther wrote:
Bootstrapped (with memset recognition enabled by default) and tested
on x86_64-unknown-linux-gnu with the aforementioned issues.
The following fixes it by simply always adding
-fno-tree-loop-distribute-patterns to builtins.exp.
Hi,
On Tue, 29 May 2012, Richard Guenther wrote:
The other change in function.c further improves the temp slot
machinery. While expanding free_temp_slots is called after each
statement, and if it is able to free a slot it needs to update the
RTX-slot mapping (a htab_t). The freeing
Hi,
On Sun, 27 May 2012, Gabriel Dos Reis wrote:
people actually working on it and used to that style. We don't want to
have a mixture of several different styles in the compiler. I (and I
expect many others) don't want anyone working around the latter by going
over the whole source
Hi,
I still had some cleanups for age-old code lying around, and thought to
bring it up to date. The whole dealing of slots for temporary stack space
in function.c was never really updated to the way we're meanwhile
expanding statements. It has facilities that aren't useful anymore. In
the
Hi,
and this is the large cleanup, removing dead code introduced by [1/3] for
real, and removing the 'keep' parameter from assign_temp and friends,
which now is always zero (in the compiler proper and in the backends).
That latter is the largest churn.
If [1/3] is approved this whole patch is
Hi,
and this is a further small cleanup. pop_temp_slots is now the same as
free_temp_slots (modulo the level-- of course), so there's no need in
calling both. (and preserve_temp_slots(NULL) is useless now).
Regstrapped on x86_64-linux together with [1/3] and [2/3], all languages
Hi,
[for certain test cases :-) ]
the temp slot cleanups I just sent where actually motivated by PR38474.
It exposes many slownesses in the compiler, but at -O0 the only remaining
one is the expand phase. expanding variables is the one thing (on my
machine here, with -O0 -g f951): 30
701 - 800 of 1253 matches
Mail list logo
