4bit ops. All 32bit ops were synthesized.
Jeff
s (and defs) of objects is ultimately going to
lead to problems. Pick one (I usually recommend explicit) and stick to
it. From what little information you've given, I'd say explicit
uses/defs is the way to go.
jeff
argets that matter anymore
and, IMHO, it's reasonable to demand ELF support for LTO. The only
other format that has a reasonable chance of working would be the COFF
variants anyway and the only COFF variant that is meaningful is used by
AIX (and perhaps Darwin?!?).
Just my $.02
Jeff
or more of the ports that haven't been converted.
Jeff
_class_and_costs): Don't set up
updated costs.
This is fine. Sorry about the long delay.
Jeff
than
define_peephole whenever possible, if you could make that change as well
it would be greatly appreciated.
Jeff
23111, 33702). Feel free to create a
GCC 4.5 pending patches PR and attach the updated patch to that PR to
ensure it doesn't get lost while we wait for the tree to return to stage1.
jeff
l;
+ return copy_rtx (desc->rtl);
}
/* Subroutine of output_constant_def: Decide whether or not we need to
-
Moreover, this can be common problem on more places (at least at
gen_rtx_CONST_INT).
Ohh, and sorry for my english.
Many thanks
Michal Meloun
Can you forward all the debugging dumps? Clearly there's a structure
sharing problem here, but I'd like to see the full dumps.
Jeff
ing+DOM stuff we're using.
I would welcome investigations into solving some of these problems and I
would certainly encourage you to submit testcases for the testsuite
which test for the missed optimizations.
Jeff
32c, Vlad has a patch which was supposed to help deal with
specific issues that arise on the m32c; that patch needs updating so
that DJ & I can look at the m32c again.
Jeff
ppens in the backend somewhere.
E.g. when it is fooling about with insn splitters (with C as
opposed to machine-generated via patterns).
A badly written LEGITIMIZE_RELOAD_ADDRESS can trigger this kind of
failure as well.
jeff
Hans-Peter Nilsson wrote:
On Tue, 9 Dec 2008, Vladimir Makarov wrote:
Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit
before submitting patch removing the old register allocator. So nothing
prevents to remove the old RA.
I am going to submit the patch removing
lorable, do we allow IRA to override the alternative selection, or
do we insert copies to simplify the conflict graph or some mixture of both?
Thoughts?
jeff
Paolo Bonzini wrote:
Jeff Law wrote:
We'd want to encode [early insn alternative selection]
information in the conflict graph so that IRA would
allocate registers so as to fit the constraints of the early insn
alternative selection. Right? In the case where the graph is
uncolorable,
them off
until after we have a solid handle on how to deal with the most common
cases.
Jeff
Steven Bosscher wrote:
On Fri, Feb 13, 2009 at 8:53 PM, Jeff Law wrote:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload
've finalized
everything in the stack -- which implies that you're done spilling.
Jeff
Vladimir Makarov wrote:
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- t
e
d0-d3/a0-a3, but which are more expensive (but still cheaper than memory).
Jeff
What purpose does changed_allocation_pseudos serve? AFAICT we set/clear
the bitmap, but never use it for anything. It was added as part of the
IRA integration. Did you have some purpose in mind for this bitmap? If
not can we just remove it?
Jeff
Ian Lance Taylor wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
I see no reason for those to stay in reload (especially since I think
reload should disappear entirely). It is reasonable to pick the total
maximum size of the stack frame, and thus resolve all displacement
constraints
Ian Lance Taylor wrote:
Jeff Law writes:
I would agree that careful relaxation of displacements is no longer as
important as it once was, I don't think we can just hand wave away
the displacement issues
1. The stack frames don't have to be that big to bump up against
these pro
pre-variant rather than the
ad-hoc implementation we have now.
Jeff
Ian Lance Taylor wrote:
Jeff Law writes:
No, that makes no sense. What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many registers will be saved on the
stack. Then we know during reg
we're still in a situation where reload can come along and muck things
up. Hence my desire to move more of the spill code generation into IRA.
Jeff
e dense -- I respect and value your opinions.
We're clearly not communicating well.
jeff
Ian Lance Taylor wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
Jeff Law writes:
No, that makes no sense. What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many regi
power in this
matter? Surely you could decide to ship GCC 4.4 with the old license,
as the official GCC maintainer? But you *choose* not to use this
power (perhaps for good reasons, but I'm unconvinced).
The GCC maintainers work on behalf of the FSF and in some matters defer
to the FSF. It's that simple.
Jeff
The steering committee was formed to deal with political issues, which
after the gcc/egcs reintegration includes most of the FSF interaction.
Ideally the steering committee would not need to exist, but reality is
unfortunately different.
Jeff
awkward for them.
I'm sorry, but I don't see it that way.
Having been on the front lines on this issue in the past, I can say our
customers certainly cared about it and therefore we (Cygnus, now Red
Hat) care about it.
Jeff
t's commonly used) that I
think is horribly bad.
Jeff
articipation in the projects, it was
clear that EGCS was more viable.
jeff
Steven Bosscher wrote:
On Sun, Mar 22, 2009 at 4:05 PM, Jeff Law wrote:
I think you're wrong. Many of these players are large companies (such
as IBM and now, RedHat). Putting them in the position of having to
"reject" the official FSF contribution is awkward for them.
ing to work in the
FSF's sandbox under certain rules and guidelines set forth by the FSF.
Jeff
Gabriel Dos Reis wrote:
On Sun, Mar 22, 2009 at 5:37 PM, Jeff Law wrote:
So what if the FSF hadn't accepted the reality of the day, and had
decided to let egcs *not* be the official GCC? Would you have pulled
the plug on egcs and gone back to the cathedral?
Personally, I
Chris Lattner wrote:
These companies really don't care about FOSS in the same way GCC
developers do. I'd be highly confident that this would still be a
serious issue for the majority of the companies I've interacted with
through the years.
Hi Jeff,
Can you please explain
Dave Korn wrote:
Jeff Law wrote:
The first camp sees FOSS toolkits as a means to help them sell more
widgets, typically processors & embedded development kits. Their belief
is that a FOSS toolkit helps build a developer eco-system around their
widget, which in turn spurs developmen
Ciao!
Steven
regno_reg_rtx[pseudo]
If you're dealing with a hard register, try ORIGINAL_REGNO
Jeff
handle each common characteristic.
Jeff
efficient code than the generic code in
reload. The generic code should be producing correct, though
potentially inefficient code.
I do agree that the target is going to need secondary reload support.
jeff
Ian Lance Taylor wrote:
Jeff Law writes:
I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
TARGET_SECONDARY_RELOAD. I don't know why cc1 crashed, you will have to
debug that.
LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this --
LEGITIMIZE_RELOAD_ADDRESS is
Adam Nemet wrote:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, case TRUNCATE): Respect value of
TRULY_NOOP_TRUNCATION
Ian Lance Taylor wrote:
Adam Nemet writes:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, case TRUNCATE): Respect value of
Adam Nemet wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
Adam Nemet writes:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx
rs on the other end of the spectrum. With that in mind
I'd ask Ian to chime in and say something about the # of warnings we
found in our own codebase vs how many of those warnings represented real
bugs vs false positives.
Jeff
eeds to remain unchanged as well.
Is this a known issue, or am I just the lucky bastard who tripped over
it and now gets to audit all the EXECUTE_IF_SET_IN_BITMAP loops?
Jeff
Richard Guenther wrote:
On Sat, Jun 20, 2009 at 4:54 PM, Jeff Law wrote:
Imagine a loop like this
EXECUTE_IF_SET_IN_BITMAP (something, 0, i, bi)
{
bitmap_clear_bit (something, i)
[ ... whatever code we want to process i, ... ]
}
This code is unsafe.
If bit I happens to be the only
deas other than writing a pass that runs before
reload and tries to fix this up?
The first thing is to understand why IRA is doing what it's doing.
We're generally better off generating a good allocation rather than
trying to clean it up post-allocation.
jeff
KING or whatever,
which would normally be off.
My biggest concern would be catching all the exit paths from the
gazillion iterators we use and making sure they all reset the readonly
flag. Ick...
jeff
the prior pass? If r14 is your stack/frame
pointer, this might point to a problem in how your port interacts with
register allocation/reload as reload can replace a pseudo with an
equivalent memory location.
Jeff
t the beginning of the function, and R5 is used to pass
> parameter. So I think maybe should also trace the parameter passing
> function.
>
Again, the best thing you can do is find the first dump file where these
problematical insns exist. That would be a huge step forward.
jeff
nd constraints reject the 2064.
Agreed. There may be cases where reload generates this as well when
there's pseudos that don't get hard registers and the pseudos have
equivalent forms. These may indicate more cases that will need
secondary reloads.
Jeff
thorny problem.
But not terribly uncommon.
Do you need to synthesize large constants? ie, what code would you
generate to load the value 0x12345 into a register?
If you need to synthesize large constants, do you need any additional
scratch registers, or can you do so using just r0?
jeff
n RTL generation, so you're doing the right thing
in this regard. I think the problem is you haven't defined your
secondary reloads yet.
jeff
ld
work with or without PREFERRED_RELOAD_CLASS defined. It also means
there's no guarantee PREFERRED_RELOAD_CLASS will be honored in all cases.
Jeff
eload? And if it is going to work fine, then keep working
> on reload part?
>
You should write your secondary reload code, but not
LEGITIMIZE_RELOAD_ADDRESS.
After your port is working well, then define LEGITIMIZE_RELOAD_ADDRESS
to optimize the code better.
jeff
it,
and if so this causes the debugging info to mention the variable. */
When you hit that breakpoint look at insn 20. If it still references
reg91, then reload thinks that (plus (mem (...))) is a valid address,
most likely due to a botched GO_IF_LEGITIMATE_ADDRESS macro.
Jeff
as reload can replace a pseudo with an
>> equivalent memory location.
>>
>>
> Exactly, But how do I prevent it, replacing a pseudo with an equivalent
> memory location, happening.
>
I'd start by looking at your GO_IF_LEGITIMATE_ADDRESS macro and/or trace
find_reloads for the problematic insn.
jeff
Jim Wilson wrote:
Dobes wrote:
I am working on a port to an architecture with some strict rules. The
restriction that I am unable to figure out how to enforce is a base
register
that is allowed in the destination operand, but not in a source operand.
GCC does not provide any way in the old
elpful unfortunately because they
don't appear to show any of the costs associated with the hard regs -
I ended up instrumenting the code to work out what I've found so far.
Yea, we could easily be missing hard reg costing information in the
dumps, but it should show coalescing decisions, which may be playing a
role here.
Jeff
Dave Korn wrote:
Jeff Law wrote:
My biggest concern would be catching all the exit paths from the
gazillion iterators we use and making sure they all reset the readonly
flag. Ick...
Heh. GCC-in-CXX would solve that for us :) or we could implement
try...finally clauses
tried to modify a bitmap while iterating over
it. I can probably break this with some ugly exit code from an iterator
(*), but it'd be a big step forward.
Jeff
(*) Imagine something like this (and related variants)
EXECUTE_IF_SET_IN_BITMAP (bitmap, 0, i, bi)
{
blah blah blah
if (bitmap
nt down that path for a while, but
couldn't ever get comfortable with the hacks necessary to ensure
iteration would ultimately finish.
Jeff
ven't bothered to look into ways to improve that situation.
Jeff
I'm
doing. I could probably be convinced to put the block local
allocation/spilling on hold to focus on benchmarking and tuning my bits
to generate spill code.
Jeff
> but the DECL_RTL of a variable decl may refer to it,
>> and if so this causes the debugging info to mention the variable. */
>>
>> When you hit that breakpoint look at insn 20. If it still references
>> reg91, then reload thinks that (plus (mem (...))) is a valid address,
&g
biner
phase of GCC doesn't know to try and optimize the two (or three)
insns.It has been our experience that peepholes are only
occasionally useful and thus we haven't spent considerable time
improving the infrastructure for the peephole optimizer.
Jeff
te address in the first place?
I'm not sure they are ever legitimized -- IIRC caller-save tries to only
generate addressing modes which are safe for precisely this reason.
Jeff
On 05/05/10 21:34, Greg McGary wrote:
On 05/05/10 20:21, Jeff Law wrote:
I'm not sure they are ever legitimized -- IIRC caller-save tries to only
generate addressing modes which are safe for precisely this reason.
Apparently not so: caller save is quite capable of producing invalid
of
rcs didn't have any call-saved FP regs.
Jeff
ch begs
the question how does purify handle this on sparc-solaris? ]
Jeff
Thanks
Hari
I've got a local port of GCC 4.5.0 to an in-house CPU.
I'm trying to remove *all* single-letter constraints from my cpu.md file and
replace them with define_constraint entries that define *multi-letter*
constraint names. Example: (define_constraint "aFOO" ...)
But I've found that when I remov
ce vzeroupper will change xmm0/ymm0, the value saved on stack is wrong.
Is that a way to tell IRA not to move an instruction?
You need to expose those operands so that the dataflow information is
correct.
jeff
r than get().
Agreed.For me at least, that style is far easier to read and
understand. It's very clear what "get" means.
Jeff
;.
And, in general, we are trying to avoid situations where seemingly
simple code does something expensive, right?
Jeff
include a keyword in their
message to gcc-patches to mark the thread as not needing 3rd party
tracking/pings.
Just thinking out loud,
Jeff
. I get it. Enough is
enough already. Technical disagreements are one thing. Personal
attacks on me are just juvenile.
I don't see this as a personal attack.
Like Paolo, I'm a lot more likely to read a message from someone with a
real name, or at least a name that sounds real.
Jeff
he complication of needing to
add specific prefixes or nops and it just gets downright ugly.
I'd probably approach this by having the compiler emit a directive which
states what the desired alignment at a particular point should be, then
allow the assembler to select the best method to get the desired alignment.
jeff
allocated to a
hard GPR preferring NO_REGS and from an allocation standpoint living in
memory.
Jeff
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char
On 06/10/10 14:44, Bernd Schmidt wrote:
On 06/10/2010 10:37 PM, Jeff Law wrote:
Compile the attached with -O2 on x86-unknown-linux-gnu and review the
.ira dump for main()
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Building IRA IR
On 06/11/10 10:48, Bernd Schmidt wrote:
On 06/11/2010 06:32 PM, Jeff Law wrote:
But shouldn't having an invariant form just decrease the priority
for pseudo 59 to get a hard register? The NO_REGS preferencing will
totally disable register allocation for pseudo 59.
And t
ia SUBREGs, others are naked REGs). So
this approach may not necessarily work.
jeff
ally a runtime redundancy, it's more like a code hoisting since on
any given iteration of the loop the expression level * qmul is only
evaluated once.
Jeff
whether or not it handles a strict & non-strict
variant properly.
Jeff
hink these days most developers largely ignore the delay slot
code and just hope it doesn't break.
Jeff
insns which branch are not allowed to have output reloads. You must
support any kind of register as well as memory operands in your insn for
the loop counter.
Jeff
HW loops with memory operands?
Emulate it using normal instructions. You can find examples in various
other ports. These situations are rare, but for proper operation, you
need to support them.
Jeff
situation. Handling of the shift
register (SAR) on the PA would be a good example. You can move the SAR
to/from a GPR, but SAR can not be stored directly to memory. Searches
for SAR in pa.c will get you a long way.
Jeff
s.
What's concerning is how much time we've got to spend discussing this
kind of issue rather than getting real work done, all due to a license
that is insanely controversial.
Jeff
Sending this to "gcc" since I got no help from sending it to "gcc-help"
--- On Sun, 8/8/10, Jeff Saremi wrote:
> From: Jeff Saremi
> Subject: Debugging plugins with gdb
> To: gcc-h...@gcc.gnu.org
> Date: Sunday, August 8, 2010, 9:52 AM
> I'd like to ste
Daniel/Andrew
thanks so much. I was using gdb version 7.1. So it understood deferred
breakpoints but as long as I started gdb with something like ~/bin/gcc it never
stopped in my function.
As soon as I switched to running gdb on cc1, it worked!
Now i can work on debugging the seg-fault i'm causin
a
different way to iterate through declarations?
thanks
jeff
static tree my_walk_stmt(gimple_stmt_iterator *gsi, bool *oprnds_handled,
struct walk_stmt_info *stmt_info)
{
int code;
gimple stmt = gsi_stmt(*gsi);
code = gimple_code(stmt);
switch(code
well, that explains it nicely. thanks
erted to RTL and such.
Any input's appreciated.
thanks
jeff
Basile,
you fully understood what I was asking. And I think I understood that I may
have to rethink what I wanted to do since the effort is seemingly out-weighing
the benefits.
thanks again.
jeff
--- On Sat, 8/28/10, Basile Starynkevitch wrote:
> From: Basile Starynkevitch
> Subje
On 08/09/10 07:28, Steven Bosscher wrote:
Hi Jeff,
I'm looking at the remaining text peepholes (define_peephole instead
of define_peephole2) and I have a few questions about mn10300, that
you are a maintainer of.
I've been out on FMLA, so sorry for the late response...
The first p
which does not need further reloading. This makes handling secondary
reloads rather complex in some cases.
jeff
That code should be handling the false
conflicts created by movement of clobbers.
jeff
The easy solution is to go ahead and invalidate the equivalency once we
notice that pseudo A crosses a call, even though the memory equivalent
is readonly. Seems a little harsh, but it's a one line change.
Other approaches?
Jeff
suitable insn constraints/predicates
you can usually arrange to avoid expensive constants in places where it
makes sense.
Perhaps if you gave us more information about the target and the
situations you're trying to avoid we could give more specific advice.
Jeff
901 - 1000 of 1403 matches
Mail list logo
