Hi,
On Thu, 27 Sep 2012, Lawrence Crowl wrote:
> > template
> > struct D : B
> > {
> > typedef typename B::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
Hi,
On Tue, 25 Sep 2012, Lawrence Crowl wrote:
> On 8/15/12, Richard Henderson 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, Lawrence Crowl wrote:
> On 9/19/12, Eric Botcazou 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, 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
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 con
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&#x
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_PREV
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 handl
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
bl
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 (an
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
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, o
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 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 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 ENTR
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, 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 w
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
> c
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
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
>
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 Fri, 3 Aug 2012, Richard Guenther wrote:
> 2012-08-03 Richard Guenther
>
> * 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): Likewise.
>
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
mea
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 tru
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
interest
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).
T
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
aren
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 i
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 0>
> before the GIMPLE_COND in bb2.
Nope. That would require some mor
Hi,
On Thu, 5 Jul 2012, Richard Guenther wrote:
> >> On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand
> >> 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 Wed, 4 Jul 2012, Steven Bosscher wrote:
> On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand 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 don't think
>
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 strip-m
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.
> >
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 not
Hi,
On Tue, 26 Jun 2012, Jason Merrill wrote:
> > (the gimplifier code should be in Frontend code that lowers to GENERIC
> > really and the WITH_CLEANUP_EXPR code should be C++ frontend specific
> > ...).
>
> TARGET_EXPR has been a back-end code since the dawn of GCC version
> control; if it'
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
tha
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 fig
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 coul
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,
> > le
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
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 abo
Hi,
now that we regard MEM_EXPR as a conservative approximation for MEM_SIZE
(and MEM_OFFSET) we must ensure that this is really the case. It isn't
currently for the string expanders, as they use the MEM_REF (whose address
was taken) directly as the one to use for MEM_EXPR on the MEM rtx. Tha
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 indee
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" m
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
|| TRE
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
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 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
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.
Tha
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 re
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 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 so
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 f
Hi,
On Fri, 25 May 2012, NightStrike wrote:
> This point of yours should be stressed. Using writing standards of
> one language to develop in another language is a fundamentally bad
> idea. C and C++ kind of look the same, but they are not:
> http://www.research.att.com/~bs/bs_faq.html#C-slash
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 seconds
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
(+Ada,+obj-c
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 l
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,
On Fri, 25 May 2012, Olivier Hainque wrote:
> > I've noticed that libitm is always rebuild with a non-bootstrap tree even
> > with merely a sequence of two makes. The reason turns out to be that
> > installation of unwind.h from libgcc, which is always done with a simple
> > make:
>
> Th
Hi,
On Fri, 25 May 2012, Diego Novillo wrote:
> > > That's one of my fears, namely that those used to the libstdc++
> > > style impose that on the compiler source base. Because IMHO the
> > > libstdc++ style isn't very appealing.
> >
> > Seconded.
>
> I don't care how ugly coding conventions
Hi,
I've noticed that libitm is always rebuild with a non-bootstrap tree even
with merely a sequence of two makes. The reason turns out to be that
installation of unwind.h from libgcc, which is always done with a simple
make:
# make
# make -d
...
dest=../.././gcc/include/tmp$$-unwind.h; \
Hi,
On Fri, 25 May 2012, Steven Bosscher wrote:
> >> Note also the almost 2 decades of C++ style practice in our libstdc++
> >> implementation.
> >
> > That's one of my fears, namely that those used to the libstdc++ style
> > impose that on the compiler source base. Because IMHO the libstdc++
Hi,
On Fri, 25 May 2012, Gabriel Dos Reis wrote:
> >> (and various other places) - formatting is wrong, missing space
> >> between (.
> >
> > And it doesn't start at the first column, and type isn't on a separate
> > line. I realize that this is a member method, hence indenting and C
> > GNU
Hi,
On Fri, 25 May 2012, Jakub Jelinek wrote:
> > + /* Return the current size of this hash table. */
> > +
> > + size_t size()
> > + {
> > +return htab->size;
> > + }
>
> (and various other places) - formatting is wrong, missing space between (.
And it doesn't start at the first colum
Hi,
On Tue, 22 May 2012, Richard Guenther wrote:
> > I had thought of that as well. But it is not quite that simple -- the
> > problem is that tree-ssa-reassoc.c as part of its core algorithm
> > reassociates
> > expressions all the time while even still building up the tree, see e.g.
> > linea
Hi,
On Mon, 21 May 2012, Richard Guenther wrote:
> This removes the code that makes us walk DECL_INITIAL (recursively)
> on add_referenced_var - one source of compile-time hogs in the past
> and not strictly necessary.
For this to be a compile time hog, ...
>if (referenced_var_check_and_ins
Hi Eric,
there's a call to expand_decl in gcc-interface/utils.c, which is used only
for setting up some field of CONST_DECLs. I'm working on removing this
function, and removing that call from utils.c is seemingly working just
fine. It came in with :
2005-11-14 Thomas Quinot
O
Hi,
On Wed, 16 May 2012, Lawrence Crowl wrote:
> > Because it accepts any type as tree argument? It's of course not less
> > type safety than using macros, but less type safety compared to not
> > using templates.
>
> The overload works if the only types are tree and const_tree. In the
> fut
Ping.
On Tue, 8 May 2012, Michael Matz wrote:
> Hi,
>
> On Mon, 7 May 2012, Mike Stump wrote:
>
> > On May 7, 2012, at 6:11 AM, Michael Matz wrote:
> > > I'd like to retain the #if 0 code therein,
> >
> > Can you structure this code as
&
Hi,
the current code for strided loads can't deal with the situation when a
prologue loop (peeling for alignment) is created after analyzing the data
refs. There are multiple issues (non-constant steps in DRs mainly), so
this is a simple stop gap.
Regtesting on x86_64-linux (all langs) in pro
his is what I checked in (r187288). Only change from
submission is the intro of BB_HEADER/BB_FOOTER macros.
Ciao,
Michael.
-------
2012-05-03 Michael Matz
* basic-block.h (struct rtl_bb_info): Remove visited member and
move head_ member t
Hi,
On Mon, 7 May 2012, Mike Stump wrote:
> On May 7, 2012, at 6:11 AM, Michael Matz wrote:
> > I'd like to retain the #if 0 code therein,
>
> Can you structure this code as
>
> #define DEBUG 0
>
> if (DEBUG) ...
>
> ?
>
> If so, that would be a
Hi,
neverending story. Maybe this time something gets in :)
This patch changes generation of insn-attrtab.c to:
* order attributes topologically (so that the "inlining" genattrtab does
is as effective as possible, and doesn't hit the size limits too much)
* adjusts the rtx_cost for the attribu
-> il.x.rtl renaming. I wish
we would accept anonymous structs for our sources, but we don't.
Currently regstrapping on x86_64-linux, okay if that passes?
Ciao,
Michael.
-
2012-05-03 Michael Matz
* basic-block.h (struct rtl_bb_info): Remove visite
e_seq that
Richi asked me for.
Regstrapped on x86_64-linux, all langs, no regressions. Okay for trunk?
Ciao,
Michael.
2012-05-02 Michael Matz
* basic-block.h (struct rtl_bb_info, struct gimple_bb_info): Move
in front of basic_block_def.
(s
Hi,
my gimple_seq reshuffling broke boostrap on some machines. In particular
on those for which contrib/compare-debug works, meaning that
bootstrap-debug is selected as default BUILD_CONFIG (none of my machines
pass the respective configure.ac test, and hence I wasn't seeing the
problem anywh
Hi,
On Wed, 2 May 2012, Richard Guenther wrote:
> Please remove the flags.
Okay.
> can you factor out this idiom to sth like gsi_new_seq_from_stmt () or so?
> Or gimple_init_seq_pointers? Not necessarily exported.
gimple_init_singleton it is. The whole series is now at r187053.
Ciao,
Micha
walkers. So, I'd be happy to take them out again, straighten the
asserts and leave uid be a normal 32bit integer. Just tell me.
As per [0/6] regstrapped with the other five patches on x86_64-linux.
Okay for trunk (with or without the start/end_of_seq flags)?
Ciao,
Michael.
-
be a functional no-op, as should be the whole 1-5
sequence of patches. As per [0/6] regstrapped with the other five on
x86_64-linux. Okay for trunk?
Ciao,
Michael.
----
2012-05-02 Michael Matz
* gimple.h (gimple_stmt_iterator ): Make it be pointer to
-05-02 Michael Matz
* gimple.h (gimple_seq_first, gimple_seq_first_stmt, gimple_seq_last,
gimple_seq_last_stmt, gimple_seq_set_last, gimple_seq_set_first,
gimple_seq_empty_p, gimple_seq_alloc_with_stmt, bb_seq,
set_bb_seq): Move down to after gimple_statement_d
of how to represent the data
structures and might not be strictly needed anymore, but I've always
tested with it, and it's definitely not harmful.
As per [0/6] regstrapped with the other five on x86_64-linux. Okay for
trunk?
Ciao,
Michael.
------
2012-05-02 Michael Matz
(A notable
exception is when the seq will be used in an iterator).
As per [0/6] regstrapped together with the other five patches on
x86_64-linux. Okay for trunk?
Ciao,
Michael.
2012-05-02 Michael Matz
* tree-phinodes.c (add_phi_node_to_bb): Tidy,
Hi,
a long time ago, during development of [tuples] gimple_statement_base had
prev/next links. Those were moved to gimple_seq_node, referred to from
gimple_seq, and referring to gimple statements, on the grounds that this
eases experimentation with different data structures. Well, those
expe
Hi,
On Thu, 19 Apr 2012, Michael Matz wrote:
> I've audited all other calls of va_end in the compiler and these were the
> only problematic ones.
Well, I did, but forgot the fact that I found one in cp/error.c, so the
generated diff and the commit forgot that file too. It
Hi,
On Mon, 16 Apr 2012, Richard Guenther wrote:
> This fixes PR52977 - for PCH to work with its pointer relocation code we
> have to avoid dereferencing pointers to compute array lengths in
> structures. So we have to unfortunately keep duplicated info about
> VECTOR_CST vector lengths.
Tha
Hi,
I observed this with an alternate implementation of the stdarg stuff that
allocs new va_lists for va_start and va_copy, and frees them on va_end.
Some routines of diagnostic.c called va_end while the va_list was still
stored away in the diag objects and used in report_diagnostic.
I've aud
Hi,
On Wed, 11 Apr 2012, Richard Guenther wrote:
> > But it would possibly be an interesting experiment already to do such
> > transformation generally (without profiling) and see what it gives on
> > some benchmarks. Just to get a feel what's on the plate.
>
> The question is, of course, why
Hi,
On Tue, 10 Apr 2012, Richard Guenther wrote:
> > + vec_inv = build_constructor (vectype, v);
> > + new_temp = vect_init_vector (stmt, vec_inv, vectype, gsi);
> > + new_stmt = SSA_NAME_DEF_STMT (new_temp);
> > + mark_symbols_for_renaming (new_stmt);
>
> This sh
Hi,
On Tue, 10 Apr 2012, Steven Bosscher wrote:
> This is OK.
r186283.
> Do you think it would be worthwhile to do this transformation in the
> middle end too, based on profile information for values?
I'd think so, but it probably requires a new profiler that counts for how
often 0 <= A <= B
Hi,
this patch speeds up polyhedrons protein on Bulldozer quite a bit. The
things is that in this testcase cshift is called with a very short length
(<=3) and that the shift amount always is less than the length.
Surprisingly the division instruction takes up considerable amount of
time, so m
Hi,
and this implements generally strided loads where the stride is a
loop-invariant (constant or ssa-name). We only do so if the load can't be
handled by interleaving groups. The implementation is fairly straight
forward:
for (i = 0; i < n; i += stride)
... = array[i];
Hi,
as preparation for the real patch in [2/2] this renames most uses of the
word "stride" (and combinations thereof) in the vectorizer to something
else. I've done this to not introduce even more confusion. The currently
supported loads/stores aren't really generally strided, but of very
co
Hi,
So here's an extended variant of my hack that implements throwing asms.
Like rth proposed I've added a new pseudo clobber, "throw":
int f (void)
{
int x, y;
x = 1;
y = 2;
try {
__asm__ ("" : "=r"(x), "=r"(y) : : "throw");
} catch (...) {
return 2+x+y;
}
return x+y;
}
Hi,
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
> +struct __processor_model
> +{
> + /* Vendor. */
> + unsigned int __cpu_is_amd : 1;
> + unsigned int __cpu_is_intel : 1;
> + /* CPU type. */
> + unsigned int __cpu_is_intel_atom : 1;
> + unsigned int __cpu_is_intel_core2 : 1;
> + unsigned i
Hi,
On Wed, 21 Mar 2012, Mike Stump wrote:
> --- a/gcc/emit-rtl.c
> +++ b/gcc/emit-rtl.c
> @@ -531,10 +531,9 @@ immed_double_const (HOST_WIDE_INT i0, HOST_WIDE_INT i1,
> enum machine_mode mode)
>
> 1) If GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT, then we use
> gen_int_mode.
Hi,
On Wed, 21 Mar 2012, Mike Stump wrote:
> > If the high bit of i1 is set then currently you will get a negative
> > number produced no matter the absolute value of it.
>
> Ok, in the new patch, I'm pushing to change the spec so that the value
> is sign extended and fixing all the code that
Hi,
On Tue, 20 Mar 2012, Mike Stump wrote:
> > Actually you did. I've tried yesterday to come up with a text that
> > would do the same (because I agree with you that deleting the assert
> > changes the spec of the function,
>
> The spec of the function is the text above the definition of the
Hi,
On Tue, 20 Mar 2012, Richard Sandiford wrote:
> If Mike or anyone is up to doing that, then great. But if instead it's
> just a case of handling zero correctly, moving rather than removing the
> assert seems safer.
>
> I'm obviously not explaining this well :-)
Actually you did. I've tr
501 - 600 of 847 matches
Mail list logo
