On Tue, 10 Oct 2023, Roger Sayle wrote:
>
> This patch is the middle-end piece of an improvement to PRs 101955 and
> 106245, that adds a missing simplification to the RTL optimizers.
> This transformation is to simplify (char)(x << 7) != 0 as x & 1.
Random observation:
So, why restrict to shi
Hello,
On Wed, 16 Sep 2020, Richard Biener wrote:
> This removes the canonicalization of X + -CST to X - CST to facilitate
> SLP vectorization analysis where we currently treat the added testcase
> as two-operation plus blend vectorization opportunity. While there
> may be the possibility to avo
Hello,
On Tue, 22 Oct 2019, Rainer Orth wrote:
> > testsuite/
> > * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case.
>
> this testcase now FAILs on 32-bit targets (seen on i386-pc-solaris2.11
> and sparc-sun-solaris2.11, also reports for i686-pc-linux-gnu and
> i586-unknown-fre
Hi,
On Wed, 23 Oct 2019, Michael Matz wrote:
> On Tue, 22 Oct 2019, Rainer Orth wrote:
>
> > > testsuite/
> > > * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case.
> >
> > this testcase now FAILs on 32-bit targets (seen on i386-pc-solaris2.11
Hello,
On Mon, 28 Oct 2019, Rainer Orth wrote:
> >> > +FAIL: gcc.dg/unroll-and-jam.c scan-tree-dump-times unrolljam "applying
> >> > unroll and jam" 6
> >>
> >> Hrmpf, I'll have a look :-/ Thanks for noticing.
> >
> > A strange interaction with LIM, which only does something on 32bit, but
> >
Hi,
On Wed, 13 Nov 2019, Martin Liška wrote:
> > Not a review, just a few questions:
>
> Hello.
>
> Thank you for it.
>
> >
> > 1) what does it do if __builtin_expect* has been used, does it preserve
> > the probabilities and if in the end decides to expand as ifs, are those
> > proba
Hi,
On Thu, 30 Jan 2020, Uecker, Martin wrote:
> > guarantees face serious implementation difficulties I think
> > so the only alternative to PVNI (which I think is implementable
> > but at a optimization opportunity cost) is one that makes
> > two pointers with the same value always have the sam
Hi,
On Thu, 30 Jan 2020, Michael Matz wrote:
> > and the pointers have the same address, then it would evaluate to true
> > at run-time. If I understand correctly, you somehow want to make this
> > case be UB, but I haven't quite understood how (if it is not the
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Where does your '50 chars' limit come from? It's not in the glibc text,
> and it's not in the linux kernel text either. AFAICT this is your
> invention and you seem to be the only person proposing it.
Nope, it's fairly common, so m
Hi,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> The idea is that the [...] part is NOT part of the commit, only part of
> the email.
I understand that, but the subject line of this thread says "e-mail
subject lines", so I thought we were talking about, well, exactly that;
and I see
Hello,
On Mon, 3 Feb 2020, Jakub Jelinek wrote:
> > > The idea is that the [...] part is NOT part of the commit, only part of
> > > the email.
> >
> > I understand that, but the subject line of this thread says "e-mail
> > subject lines", so I thought we were talking about, well, exactly that;
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Well, I'd review a patch differently depending on whether or not it was
> already committed, a patch requiring review or an RFC looking for more
> general comments, so I *do* think such an email prefix is useful.
As I said: a very go
Hi,
On Thu, 5 Dec 2019, Richard Biener wrote:
> On December 5, 2019 3:35:17 PM GMT+01:00, Tom Tromey wrote:
> >> "Martin" == Martin Liška writes:
> >
> >Martin> + /* Default constructor. */
> >Martin> + symtab_node (symtab_type t)
> >
> >FWIW, in gdb, we normally make single-argument con
Hello,
(oh a flame bait :) )
On Thu, 5 Dec 2019, Thomas Schwinge wrote:
> So, I formally propose that we lift this characters per line restriction
> from IBM punch card (80) to mainframe line printer (132).
>
> Tasks:
>
> - Discussion.
I object to cluttering code in excuse for using sensibl
Hi,
On Thu, 5 Dec 2019, Richard Biener wrote:
> >> Indeed - please adjust that as well.
> >
> >Explicit ctors are a c++11+ feature.
>
> Surely not.
Whoops, I was conflating ctors and conversion functions, the latter can
be explicit only in c++11+.
Ciao,
Michael.
Hello,
On Fri, 28 May 2021, Bernd Edlinger wrote:
> >> I was wondering, why gimple-match.c and generic-match.c
> >> are not built early but always last, which slows down parallel
> >> makes significantly.
> >>
> >> The reason seems to be that generated_files does not
> >> mention gimple-match.c a
Hello Martin,
On Mon, 31 May 2021, Martin Liška wrote:
> I've made quite some progress with the porting of the documentation and
> I would like to present it to the community now:
> https://splichal.eu/scripts/sphinx/
>
> Note the documentation is automatically ([1]) generated from texinfo with
Hello,
On Tue, 1 Jun 2021, Martin Liška wrote:
> On 5/31/21 5:49 PM, Michael Matz wrote:
> > Hello Martin,
> >
> > On Mon, 31 May 2021, Martin Liška wrote:
> >
> >> I've made quite some progress with the porting of the documentation and
> >&g
Hello,
On Mon, 7 Jun 2021, Jeff Law wrote:
>
> So, as many of you know I left Red Hat a while ago and joined Tachyum. We're
> building a new processor and we've come across an issue where I think we need
> upstream discussion.
>
> I can't divulge many of the details right now, but one of the q
Hello,
On Tue, 8 Jun 2021, Jeff Law wrote:
> On 6/8/2021 9:06 AM, H.J. Lu wrote:
> > On Tue, Jun 8, 2021 at 7:56 AM Jakub Jelinek via Gcc-patches
> > wrote:
> >> On Tue, Jun 08, 2021 at 08:47:26AM -0600, Jeff Law wrote:
> Why is the machinery involving STACK_SLOT_ALIGNMENT and
> spill_
Hello,
On Mon, 3 May 2021, Jan Hubicka wrote:
> > (it should not abort). The documentation of 'pure' must be read
> > as that 'pure' is not valid for 'foo' since throwing an exception
> > is obviously an observable effect on the state of the program
> > (in particular for the testcase at hand).
Hey,
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> > @@ -1712,12 +1711,9 @@ compute_idf (bitmap def_blocks, bitmap_head *dfs)
> >gcc_checking_assert (bb_index
> >< (unsigned) last_basic_block_for_fn (cfun));
> >
> > - EXECUTE_IF_AND_COMPL_IN_BITMAP (&dfs[bb_in
Hello,
On Thu, 4 Apr 2024, Richard Biener wrote:
> I have reworded the comment before the all-to-all conflict recording
> since it seemed to be confusing and missing the point - but maybe I
> am also missing something here.
The point of the comment was to explain how this differs from building a
Hello,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> So, the following patch adds a flag during preprocessing at the point
> where we normally create CPP_SCOPE tokens out of 2 consecutive colons
> on the first CPP_COLON to mark the consecutive case (as we are tight
> on the bits, I've reused the PU
Hi,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> > Hmm, shouldn't you be able to use (nonexistence of) the PREV_WHITE flag on
> > the second COLON token to see that it's indeed a '::' without intervening
> > whitespace? Instead of setting a new flag on the first COLON token?
> >
> > I.e. somet
Hello,
On Mon, 26 Feb 2024, Jakub Jelinek wrote:
> > Will update the patch, I think any improvement should be done
> > to get_range_pos_neg (it's a bit odd in behavior for unsigned
> > but I have only signed things incoming).
>
> For unsigned if it always returned 1, it would be quite useless, t
Hello,
On Tue, 27 Feb 2024, Jakub Jelinek wrote:
> On Tue, Feb 27, 2024 at 10:13:14AM +0100, Jakub Jelinek wrote:
> > For __libc_start_main, glibc surely just could use no_callee_saved_registers
> > attribute, because that is typically the outermost frame in backtrace,
> > there is no need to sav
Hello,
On Wed, 17 Jan 2024, Ajit Agarwal wrote:
> > first is even, since OOmode is only ok for even vsx register and its
> > size makes it take two consecutive vsx registers.
> >
> > Hi Peter, is my understanding correct?
> >
>
> I tried all the combination in the past RA is not allocating seq
Hello,
I have implemented the separate shrink wrapping hooks for x86, and this is
the result. With it we can now generate the pro- and epilogue sequences
individually and possibly split over multiple BBs, unlike the non-separate
shrink wrapping we implement (which can only move the whole
prol
On Tue, 21 May 2024, Andi Kleen wrote:
> - Give error messages for all causes of non sibling call generation
> - When giving error messages clear the musttail flag to avoid ICEs
> - Error out when tree-tailcall failed to mark a must-tail call
> sibcall. In this case it doesn't know the true reason
Hello,
On Fri, 31 May 2024, Andi Kleen wrote:
> > I think the ultimate knowledge if a call can or cannot be implemented as
> > tail-call lies within calls.cc/expand_call: It is inherently
> > target and ABI specific how arguments and returns are layed out, how the
> > stack frame is generated,
Hello,
On Mon, 3 Jun 2024, Jakub Jelinek wrote:
> > Hmm. I count six tests in about 25 lines of code in
> > tree-tailcall.cc:suitable_for_tail_opt_p and suitable_for_tail_call_opt_p.
> >
> > Are you perhaps worrying about the sibcall discovery itself (i.e. much of
> > find_tail_calls)? Why w
this is part of making m68k work with LRA. See PR116374.
m68k has the property that sometimes the elimation offset
between %sp and %argptr is zero. During setting up elimination
infrastructure it's changes between sp_offset and previous_offset
that feed into insns_with_changed_offsets that ultima
This is part of making m68k work with LRA. See PR116429.
In short: setup_sp_offset is internally inconsistent. It wants to
setup the sp_offset for newly generated instructions. sp_offset for
an instruction is always the state of the sp-offset right before that
instruction. For that it starts at
when experimenting with m68k plus LRA one of the
changes in the backend is to accept ASHIFTs (not only
MULT) as scale code for address indices. When then not
turning on LRA but using reload those addresses are
presented to it which chokes on them. While reload is
going away the change to make the
Hello,
On Sun, 25 Aug 2024, Jeff Law wrote:
> >550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
> >551: [--sp] = 37sp_off = -4 {pushexthisi_const}
> >552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
> >554: [--sp] = r116 - r37sp_off = -12 {subsi3}
>
Hello,
On Mon, 26 Aug 2024, Paul Koning wrote:
> >>> 550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
> >>> 551: [--sp] = 37sp_off = -4 {pushexthisi_const}
> >>> 552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
> >>> 554: [--sp] = r116 - r37sp_off = -12 {su
Hello,
On Mon, 26 Aug 2024, Paul Koning wrote:
> >>> Yeah, I wondered as well. For things to go wrong some instructions that
> >>> contain pre/post-inc/dec of the stack pointer need to have reloads in
> >>> such
> >>> a way that the actual SP-change sideeffect moves to a different
> >>> inst
Hello,
On Wed, 19 Jun 2024, Tamar Christina wrote:
> So this is where we compare different IV expressions to determine which
> IVs compute the same thing and thus can be in the same group.
>
> The STRIP_NOPS don't work because while the incoming types are the same
> the casts are different. So:
Hi,
On Wed, 21 Aug 2013, Richard Biener wrote:
> I also fail to see why threads should not work here. Maybe simply
> annotate gcc with openmp?
Threads simply don't work here, because the whole streamer infrastructure
(or anything else in GCC for that matter) isn't thread safe (you'd have to
Hi,
On Thu, 29 Aug 2013, Richard Biener wrote:
> > Fork-fire-forget is really a much simpler choice here IMO; no worries
> > about shared resources, less debug hassle.
>
> It might be not as cheap as it is on Linux hosts on other hosts of
> course.
Sure. Don't use it there then. Not a reason
Hi,
On Thu, 29 Aug 2013, David Malcolm wrote:
> Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> testcases show the same results as an unpatched build (relative to
> r202029).
I'd like to see some statistics for cc1{,plus} codesize and for compile
time of something reason
Hi,
On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
>
> >> I thought the principle that was acquired was that gengtype shouldn't
> >> be improved to support more than what it does now….
> >
> > If it means that we'll need to write and maintai
Hi,
On Fri, 30 Aug 2013, David Malcolm wrote:
> Here's the result of a pair of builds of r202029 without and with the
> patches, configured with --enable-checking=release, running "make", then
> stripping debuginfo [1]
>
> So the overall sizes of such binaries are essentially unchanged.
Yep, co
Hi,
On Tue, 3 Sep 2013, David Malcolm wrote:
> > I can't really say I find this shorter, easier to read, more
> > expressive or even safer than what was there before. And the
> > repetition for adding the helpers for const and non-const types
> > all the time doesn't make it bet
Hi,
On Thu, 5 Sep 2013, Richard Biener wrote:
> > (1) whether it's OK for wide_ints to be writable.
> >
> > The interface already exposed the idea of an array of blocks,
> > via get_val() and get_len(). The question here is whether it is OK
> > to also have the corresponding write f
Hi,
On Thu, 5 Sep 2013, Andrew MacLeod wrote:
> 1 - I think we ought to split out the data structures from gimple.h into
> gimple-core.h, like we did with tree.h
Why?
> gimple.h. That won't really affect my work. I think it probably ought to be
> done for clarity eventually.gimple.h wou
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> >> Where? I don't see config/alpha.c listed anywhere.
> >
> > Must be in one of the fragments in config/ or config/alpha. For
> > i386 it's config/i386/t-i386
>
> Well, we have a problem here. The dependencies from t-* files are
> ignored
Why do yo
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> > Why do you think so? The t-* frags are includes via
> > ...
> > tmake_file=...$(srcdir)/config/i386/t-i386
> > ...
> > ifneq ($(tmake_file),)
> > include $(tmake_file)
> > endif
> > ...
> >
> > It's just that there's no t-alpha frag yet.
>
> No, t
Hi,
On Wed, 18 Sep 2013, Zhenqiang Chen wrote:
> The patch is updated according to your comments. It is a basic support,
> which does not touch ifcombine and jump related optimizations yet.
>
> Current method is:
> 1) In fold-const, if HAVE_conditional_compare, set
> LOGICAL_OP_NON_SHORT_CIRCUIT
Hello,
On Tue, 17 Sep 2013, Jeff Law wrote:
> I put the attached patch through a bootstrap and regression test cycle on
> x86_64-unknown-linux-gnu. As expected no regressions. Installed onto the
> trunk.
>
> Thanks Trevor!
You missed one comment style nit, and some ChangeLog entry nits.
I'm
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
> On 09/18/2013 10:24 AM, Michael Matz wrote:
> >
> > I'm irritated by the member name uglification (e.g. equiv_stack_ with
> > trailing underscore). I know that's a certain style to mark private
> > members, but I t
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
> > I know, and I don't like it there either.
>
> Well, as Ian pointed out, it is in our recommended style guidelines and
> you'll find uses in the vec class as well.
As I said, yes; I also said those were pre-existing from the C times
already, so they
Hi,
On Fri, 20 Sep 2013, Trevor Saunders wrote:
> > > very ugly FWIW. I only added the underscores because that's what
> > > the conventions said.
> > >
> > > But we're never going to get consensus on this kind of thing. E.g.
> > > I know some people really hate the GNU formatting style (alth
Hi,
On Fri, 20 Sep 2013, David Malcolm wrote:
> Treat GTY structs that have a "desc" as being the root of an inheritance
> hierarchy. Generate a switch on desc within the marking function with
> cases for each subclass, visiting all fields of the type (including
> inherited ones).
Yay! Thanks
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
> > > I was going to bring it up at some point too. My preference is
> > > strongly to simply eliminate the space on methods...
> > Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
> Yea. I actually reviewed the libstdc++ guide
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
> My example in this form would look something like:
> int unsignedsrcp = ptrvar.type().type().type_unsigned();
>
> <...>
> GimpleType t1 = ptrvar.type ();
> GimpleType t2 = t1.type ();
Stop that CamelCase dyslexia already, will you? ;-)
Ciao,
M
Hi,
On Mon, 30 Sep 2013, Jeff Law wrote:
> > - the compiler better do an awesome job of sharing stack space for
> > user variables in a function... I wouldn't want to blow up the stack
> > with a bazillion unrelatd temps each wit their own location.
> If the objects have the same type and disj
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 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
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 checkin
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
> > &g
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 UNDEF
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 AF
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 propaga
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 pr
Hi,
On Mon, 29 Oct 2012, Dehao Chen wrote:
> On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 29 Oct 2012, Richard Biener wrote:
> >
> >> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
> >> >
Hi,
On Tue, 30 Oct 2012, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen 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 in the
Hi,
On Tue, 15 Oct 2013, Richard Biener wrote:
> On Sun, Oct 6, 2013 at 2:22 PM, Bernd Edlinger
> wrote:
> > How I should proceed with this patch, is it OK?
> >
> > The latest version was posted at:
> > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00234.html
>
> I have now attached a quick dra
Hi,
I just hit this problem where gengtype thought an existing gt-*.h header
was the same as what it wanted to write because its prefix was indeed
equal to the buffer, but contained some additional things afterwards.
gengtype simply forgot to check that the file end is reached at buffer
end.
Hi,
this has bothered me for some time. The gcc configure with stage1 feels
like taking forever because some of the decl availability tests (checking
for C function) include system.h, and that, since a while, unconditionally
includes and under C++, and we meanwhile use the C++
compiler for
Hi,
On Fri, 22 Jan 2016, Oleg Endo wrote:
> and have been put into system.h because there have
> been problems with malloc poisoning and C++ stdlib implementation other
> than libstdc++, which sometimes pull other headers which then cause
> trouble. The fix for this set of errors was to inc
Hi,
On Thu, 21 Jan 2016, Richard Biener wrote:
> I'm inclined to say #define INCLUDE_ALGORITHM is a better name,
I've done this. On a different (slower) machine than the one from the
initial mail:
without patch, -j31 bootstrap all,ada:
real35m2.655s
user395m28.135s
sys 12m10.814s
Hi,
On Fri, 22 Jan 2016, Jakub Jelinek wrote:
> > > This may have caused:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69434
> >
> > Guess we need:
> >
> > 2016-01-22 Jakub Jelinek
> >
> > PR bootstrap/69434
> > * genrecog.c: Define INCLUDE_ALGORITHM before including sy
Hi,
On Mon, 25 Jan 2016, Uros Bizjak wrote:
> This patch caused bootstrap failure on non-c++11 bootstrap compiler
> [1], e.g. CentOS 5.11.
>
> The problem is with std::swap, which was defined in header
> until c++11 [2].
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
> [2] http://e
Hi,
On Tue, 26 Jan 2016, Uros Bizjak wrote:
> > Meh. Can you try the attached patch with a configure test (it
> > includes the generated files)? It works for me with 4.3.4, and should
> > make your build include always.
>
> Yes, this patch works for me and allows bootstrap with gcc-4.1.2 to
Hi,
On Mon, 8 Feb 2016, Richard Biener wrote:
> 429.mcf 9120243 37.6 S9120245 37.3 S
> 429.mcf 9120224 40.7 S9120241 37.8 *
> 429.mcf 9120225 40.5 *9120229 39.9 S
> 471.omne
Hi,
On Wed, 10 Feb 2016, Richard Biener wrote:
> > The problem is that TV_PHASE_DBGINFO is now nested within
> > TV_PHASE_OPT_GEN, which violates the above mutual exclusivity
> > requirement. Therefore the attached patch simply gets rid of
> > TV_PHASE_DBGINFO (as well as of the sibling TV_PH
Hi,
On Wed, 10 Feb 2016, David Malcolm wrote:
> > +static timevar_id_t global_phase;
>
> FWIW I like the idea, but could this be a private field within class
> timer, rather than a global?
Sure, consider the patch amended accordingly.
Ciao,
Michael.
Hi,
On Mon, 15 Feb 2016, Jakub Jelinek wrote:
> + /* If op is default def SSA_NAME, there is no place to insert the
> + new comparison. Give up, unless we can use OP itself as the
> + range test. */
> + if (op && SSA_NAME_IS_DEFAULT_DEF (op))
> +{
> + if (op == range->exp
> +
Hi,
On Mon, 22 Feb 2016, Jeff Law wrote:
> > never considers them as candidates. However, we do seem to have proper
> > data flow information for them.
IMO one of the points of global reg vars, and its long-standing
documentation to that effect, is that we do not have proper data flow
informat
Hi,
On Wed, 24 Feb 2016, Martin Liška wrote:
> >> grep ENABLE_CHECKING *.[ch]
> > dwarf2out.c:#if ENABLE_CHECKING
> > dwarf2out.c:#if ENABLE_CHECKING
> > dwarf2out.c:#if ENABLE_CHECKING
> > dwarf2out.h:#if ENABLE_CHECKING
>
> Hi Richi.
>
> Removal in dwarf2out.c is not possible due to assignmen
Hi,
On Fri, 26 Feb 2016, Bernd Schmidt wrote:
> Calls do, asms currently don't AFAICT. Not sure whether it's allowed to
> use them, but I think it should be straightforward to adjust df-scan.
>
> > Some jit-like code uses global reg vars to reserve registers for the
> > generated code. It wou
Hi,
On Mon, 29 Feb 2016, Bernd Schmidt wrote:
> On 02/29/2016 06:07 PM, Michael Matz wrote:
>
> > %rbx would have to be implicitly used/clobbered by the asm. In addition
> > it would have to be used by all function entries and exits (so that a
> > function body whe
Hi,
On Mon, 29 Feb 2016, Mikael Pettersson wrote:
> Well, almost. While it is true that a signal handler cannot
> *accidentally* clobber the register state of the interrupted thread, it
> can in fact access and update any part of that state via the ucontext_t
> passed to it. Doing so is unco
Hi,
On Fri, 10 Jul 2015, Richard Biener wrote:
> > I also noticed it but didn't care ;) But now I notice
> >
> > switch (TREE_CODE (t))
> > {
> > case SSA_NAME:
> >
> > cases are indented too much, it should be
> >
> > switch (TREE_CODE (t))
> > {
> > case SSA_NAME:
I like
Hi,
On Sun, 12 Jul 2015, Tom de Vries wrote:
> > I'm trying to get to a defined policy for what is allowed for caches.
> > Either forbidding or allowing multi-step dependencies, I don't really
> > mind.
I think forbidding is the way to go, because ...
> > I managed to write a patch series tha
Hi,
On Mon, 13 Jul 2015, Tom de Vries wrote:
> > Implementing multi-step maps or making the hashmaps non-caching
> > doesn't solve any of the above problems
>
> I'm not saying that making those hashmaps non-caching solves any of
> these problems.
Ah, I didn't mean to imply this, I meant to im
Hi,
On Mon, 13 Jul 2015, Richard Biener wrote:
> On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson wrote:
> > On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
> > wrote:
> >> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson
> >> wrote:
> >>>signed sub-word locals. Thus to detect the need for a conve
Hi,
On Tue, 14 Jul 2015, Richard Earnshaw wrote:
> > I think it's a backend bug that parameters and locals are extended
> > differently. The code in tree-outof-ssa was written with the
> > assumption that the modes of RTL objects might be different (larger)
> > than the tree types suggest, bu
Hi,
On Tue, 14 Jul 2015, Jim Wilson wrote:
> Now that we do have the problem, we can't fix it without an ARM port ABI
> change, which is undesirable, so we may have to fix it with a MI change.
What's the ABI implication of fixing the inconsistency?
> There were two MI changes suggested, one wa
Hi,
On Tue, 14 Jul 2015, Richard Biener wrote:
> For example have those special caches have two marking phases. The first
> phase marks all non-key edges originating from each entry. The second
> phase is the same as what we have now - unmarked entries get removed.
>
> The first phase would go
Hi,
On Tue, 14 Jul 2015, Richard Biener wrote:
> I know Micha detests the extra 'if' as much as the extra braces thus
> would have prefered
>
> (switch
> (A) B
> (B) C
> (C) D
> E)
The lispy way would have been
(switch
(A) (B)
(C) (D)
(E) (F)
G)
i.e. parenthesize t
Hi,
On Wed, 15 Jul 2015, Jakub Jelinek wrote:
> On Wed, Jul 15, 2015 at 04:14:07PM +0200, Michael Matz wrote:
> > That's Toms other approach with supporting multi-step dependencies. As I
> > have tried to argue in the other thread, I think this idea is
> > fundament
Hi,
On Wed, 15 Jul 2015, Jakub Jelinek wrote:
> > No, I really meant value. If you think it has meaning, then tell me
> > what it is for DECL_VALUE_EXPR (X) to be 'Y', if Y is nowhere else
> > mentioned, neither in code, nor in local-decls, nor in globals, or
> > anywhere else that would be r
Hi,
On Wed, 15 Jul 2015, Michael Matz wrote:
> Similar for "ptr->foo" if "ptr" is nowhere mentioned in code or tables.
> In effect DECL_VALUE_EXPR refers to stale decls that aren't initialized,
> aren't given a place and aren't dealt with in
Hi,
On Wed, 15 Jul 2015, Richard Biener wrote:
> >> (switch
> >> (A) B
> >> (B) C
> >> (C) D
> >> E)
> >
> >The lispy way would have been
> >
> > (switch
> >(A) (B)
> >(C) (D)
> >(E) (F)
> >G)
> >
> >i.e. parenthesize the result as well, which then would be unambiguousl
Hi,
On Wed, 15 Jul 2015, Richard Biener wrote:
> >Or, maybe we're talking past each other. You mean the case where
> >complicated-expr-on-Y is the value-expr, and Y is _no_ stale decl, but
> >the complicated expr itself nevertheless is mentioned nowhere else?
> >Yes, those trees must be reta
Hi,
On Thu, 16 Jul 2015, Richard Biener wrote:
> > Similar, if the condition is an atom you should be able to leave the
> > parens away:
> >
> > (switch
> > cond (minus @0 @1)
> > )
> >
> > (given a predicate 'cond' defined appropriately).
>
> Yes. Though techincally the condition cannot
1 - 100 of 880 matches
Mail list logo
