Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
typedef struct sTestUnsignedChar {
uint64_t a:1;
}STestUnsignedChar;
uint64_t getU (STestUnsignedChar a)
{
return a.a;
}
I get this in the DCE pass :
(insn 6 3 7 2 bitfield2.c:8 (set (subreg:DI (reg:QI 75) 0)
Mat Hostetter writes:
Adam Nemet adambne...@gmail.com writes:
Ian Lance Taylor i...@google.com writes:
Mat Hostetter mhostet...@tilera.com writes:
Since the high bits are already zero, that would be less efficient on
most platforms, so guarding it with something like this would
Ian Lance Taylor i...@google.com writes:
Mat Hostetter mhostet...@tilera.com writes:
Since the high bits are already zero, that would be less efficient on
most platforms, so guarding it with something like this would probably
be smarter:
if (targetm.mode_rep_extended (mode, GET_MODE(x))
fanqifei writes:
2010/1/18 Adam Nemet adambne...@gmail.com:
Sorry for jumping in late. See make_file_assigment in combine.c.
The problem usually is that:
(set A (ior (and B C1) OTHER))
can only be turned into a bit-insertion if A and B happen to be the same
pseudos.
Adam
fanqifei fanqi...@gmail.com writes:
Paolo Bonzini said that insv instruction might be synthesized
later by combine. But combine only works on at most 3 instructions and
insv is not generated in such case.
So exactly when will the insv pattern be recognized and how does
the coding
Paul Brook p...@codesourcery.com writes:
Nothing you've said changes the fact that there are a class of users
for whom that information is vital and we ought to spend some time
thinking about how to provide the information in a form they can
digest. GCC dumps as they exist today are largely
Diego Novillo dnovi...@google.com writes:
If anyone has free cycles I would appreciate results from other
ELF-capable targets.
The branch on mipsisa64-elf looks good (no regressions with languages
c,c++,objc):
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02717.html
baseline:
Richard Henderson writes:
On 08/28/2009 12:38 AM, Adam Nemet wrote:
... To assist the linker we need to annotate the indirect call
with the function symbol.
Since the call is expanded early...
Having experimented with this on Alpha a few years back,
the only thing I can suggest
Richard Henderson writes:
On 09/01/2009 12:48 PM, Adam Nemet wrote:
I see. So I guess you're saying that there is little chance to optimize the
loop I had in my previous email ;(.
Not at the rtl level. Gimple-level loop splitting should do it though.
Now suppose we split late
On MIPS, PIC calls are indirect calls that need to be dispatched via an ABI
mandated register. At expansion time we load the symbol into a pseudo then
expand the call. There is a linker optimization that can turn these indirect
calls into direct calls under some circumstances. This can improve
Charles J. Tabony writes:
Filed as PR 41171.
Thanks.
Is this actually a performance regression on MIPS? I suspect either
sequence would be the same performance on most machines.
Yes it is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171#c1
Adam
Charles J. Tabony tabon...@austin.rr.com writes:
I see the same difference between GCC 4.3.2 and 4.4.0 when compiling
for PowerPC, MIPS, ARM, and FR-V.
I can confirm this with mainline on MIPS/Octeon. Can you please file a
bug.
Adam
Markus L markusl.s...@gmail.com writes:
I run into an assert in convert_memory_address not beeing able to
convert the address rtx (beeing HImode) into to Pmode (i.e. QImode). A
few frames up the I can dump the tree node and it looks like the
address calculations are done in HImode. Why is the
Jean Christophe Beyler writes:
As we can see, all three are using the symbol_ref data before adding
their offset. But after cse, we get this:
(insn 5 2 6 2 ex1b.c:8 (set (reg/f:DI 74)
(const:DI (plus:DI (symbol_ref:DI (data) var_decl 0xb7d35058 data)
(const_int 8
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
uint64_t foo (void)
{
return data[0] + data[1] + data[2];
}
And this generates :
la r9,data
la r7,data+8
ldd r6,0(r7)
ldd r8,0(r9)
ldd r7,16(r9)
I'm trying to see if there is a problem with my
Ian Lance Taylor i...@google.com writes:
I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other bootstraps, cross-compilers--to see how well
it works. Please let me know if you run into problems that you don't
know how, or don't have time, to fix.
Ian Lance Taylor i...@google.com writes:
I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other bootstraps, cross-compilers--to see how well
it works. Please let me know if you run into problems that you don't
know how, or don't have time, to fix.
Jeff Law writes:
Ian Lance Taylor wrote:
Adam Nemet ane...@caviumnetworks.com 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
Ian Lance Taylor writes:
truncate has a machine independent meaning.
Yes, I guess with your definition below it does. It's interesting though that
Jim had said the opposite in the excerpts posted by Jeff:
And a later message from Jim:
Truncate converts a value from a larger to a smaller
Ian Lance Taylor writes:
I'm not entirely sure, but I don't think Jim said the opposite. He said
that the way truncate works is machine dependent. I said that the
output of truncate is machine independent. Since truncate is only
defined for fixed-point modes, I think both statements are
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.
Index: combine.c
Ian Lance Taylor writes:
I agree that this patch looks wrong in todays compiler. There should be
no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow.
Thanks.
Do you think we can assume this for TRUNCATEs in general or only for MIPS-like
TRUNCATEs?
I can't think of why it
Revital1 Eres e...@il.ibm.com writes:
Hello,
i386-pc-solaris:
cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function
'loop_prefetch_arrays':
/export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error:
format '%ld'
Andrew Haley a...@redhat.com writes:
We need something more like I think Fred Bloggs knows gcc well enough
to approve patches to reload or I am Fred Bloggs and I know gcc well
enough to approve patches to reload.
And whom should such email be sent to? The SC is best reached on gcc@
but I
In this testcase:
struct s
{
unsigned long a:2;
unsigned long b:40;
unsigned long c:22;
};
f (struct s s)
{
g (((unsigned long) (s.b-8)) + 8);
}
fold breaks the code. Specifically, after a few transformations we're asked
to fold this. (I changed the big constant
Steven Bosscher stevenb@gmail.com writes:
Is there a way to get the REG for a given regno? I am building a
register renumbering map that is just a pair of unsigned int
old_regno, new_regno, but I can't figure out how to get the REG for
new_regno without remembering a pointer to it myself.
Jamie Prescott jpre...@yahoo.com writes:
static inline int set_prop(char const *path, char const *name,
void const *data, int size)
{
int error;
asm volatile (int\t11\n\t
: =a0 (error): a0 (path), a1 (name), a2
Jamie Prescott writes:
From: Adam Nemet ane...@caviumnetworks.com
Jamie Prescott writes:
static inline int set_prop(char const *path, char const *name,
void const *data, int size)
{
int error;
asm volatile (int\t11\n\t
Adam Nemet ane...@caviumnetworks.com writes:
I am not exactly sure what has exposed this but the bug seems to be old.
can_throw_external in except.c does not look at the branch delay slot (second
entry in a SEQUENCE) to determine whether the insn may throw or not.
In gcc.dg/cleanup-8.c
John David Anglin writes:
The same tests now fail on hppa. This is PR 39651. I'm fairly certain
this was introduced by the following change:
I put this PR in the checkin that was just approved on gcc-patc...@. Please
close the bug if it fixes the failures on hppa too.
Adam
Adam Nemet ane...@caviumnetworks.com writes:
For two testresults now the cleanup tests are failing in both gcc and g++:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html
I waited for another testresults because
For two testresults now the cleanup tests are failing in both gcc and g++:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html
I waited for another testresults because there were some bug fixes in this
area after the eh
Thank you very much. This was very informative.
Richard Sandiford writes:
If we have an instruction:
A: (set (reg Z) (plus (reg X) (const_int 0xdeadbeef)))
we will need to use something like:
(set (reg Y) (const_int 0xdead))
(set (reg Y) (ior (reg Y) (const_int
Richard Sandiford writes:
Adam Nemet ane...@caviumnetworks.com writes:
* Synthesizing multi-insns constants from const anchors make sense
regardless
whether the constant is used as an address so I am adjusting the cost system
to make those stick independent of the context. I still need
Richard Sandiford writes:
Adam Nemet ane...@caviumnetworks.com writes:
In order for my CSE const anchor patch to work I needed to drastically lower
the cost of immediate addition in the MIPS backend. This was acceptable as
a
proof of concept but not in general of course.
The problem
In order for my CSE const anchor patch to work I needed to drastically lower
the cost of immediate addition in the MIPS backend. This was acceptable as a
proof of concept but not in general of course.
The problem is with single-insn/simple constants. We would also like these
to use const
Jean Christophe Beyler writes:
I set up your patch and I get an internal error on this test program:
You're right. I haven't handled the case properly when the constant itself
was an anchor constant (e.g. 0). Try this version.
Adam
* cse.c (get_const_anchors): New function.
Ramana Radhakrishnan writes:
[Resent because of account funnies. Apologies to those who get this twice]
Hi,
This problem is reported every once in a while, all targets with
small
load-immediate instructions suffer from this, especially since GCC
4.0
(i.e. since tree-ssa). But
Steven Bosscher stevenb@gmail.com writes:
On Sun, Mar 15, 2009 at 11:19 PM, Ramana Radhakrishnan
raman...@gmail.com wrote:
I'm not sure about the best way to fix this but I've filed this for
the moment as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
This problem is reported every
Thanks for measuring these.
Laurent GUERBY laur...@guerby.net writes:
For bzip2 trunk regress badly in performance against 4.3.2
but n32 is indeed relatively faster than 32 (still slower than 4.3.2).
For gzip trunk matches 4.3.2 but n32 is slower than 32 and 64 even
slower.
Last time I
Adam Nemet ane...@caviumnetworks.com writes:
I am actually looking at something similar for PR33699 for MIPS. My plan is
to experiment extending cse.c with putting anchor constants to the available
expressions along with the original constant and then querying those later for
constant
Rahul Kharche ra...@icerasemi.com writes:
GCSE won't help with your trimmed down example
int main(void)
{
long a = 0xcafecafe;
printf(Final: %lx %lx %lx\n, a, a+5, a+15);
return EXIT_SUCCESS;
}
I believe Paolo's canon_reg solution together with tweaking
rtx_cost of
Bernd Schmidt bernds_...@t-online.de writes:
Take a look at reload_cse_move2add.
I don't think that powerful enough; it requires the same destination
registers:
/* Try to transform (set (REGX) (CONST_INT A))
...
Yoriko Komatsuzaki yor...@sm.sony.co.jp writes:
Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD
on mips ?
I have a WIP patch for this but was holding back mostly because of stage3/4
and that I was trying to make FRAME_GROWS_DOWNWARD the default and I was
running into
Richard Sandiford writes:
How about the patch below? I'll apply it in the next couple of days
if there are no objections.
Thanks for patch. I also like the new comments you added.
Adam
-msym32 changes DWARF's address_size from 64 bits to 32 bits. This means that
while symbols are 64-bit (due to ELF64), target addresses in the debug info
are 32-bit.
There is support for this in DWARF of course in fact you can specify different
address_size for each compilation unit which nicely
struct s
{
char a:4;
char b:8;
char c:4;
} __attribute__ ((packed))
is 3 bytes long because b gets pushed to the next byte boundary.
You would think that similarly:
struct t
{
char a:4;
short b:16;
char c:4;
} __attribute__ ((packed))
would come out to be 4 bytes long. However,
Ian Lance Taylor [EMAIL PROTECTED] writes:
Ralf Corsepius [EMAIL PROTECTED] writes:
So what would you recommend: To use gcc -r or gcc -Wl,-r ?
Ah, when you put the question like that, I would recommend ld -r.
This is the one case where you get no advantage from using the gcc
driver to
Ralf Corsepius writes:
So, my questions actually were aiming at
* whether
gcc ... -nostdlib -r
and
gcc ... -nostdlib -Wl,-r
are equivalent
* if the fact that gcc -r appears to work, can be exploited or whether
this is a random accident and/or intentionally undocumented feature,
I am working on FRAME_GROWS_DOWNWARD for MIPS and I am seeing two performance
issues with the code generated. The first one has to do with the order how
expand_stack_vars places locals on the stack.
Consider this function (simplified from CSiBE's
replaypc-0.4.0.preproc:find-GOPs):
f ()
{
Hi David,
David Daney writes:
gcc.target/mips/octeon-exts-2.c is failing when configured --with-arch=sb1
Do you know if it is failing universally or only on non-octeon targets?
It's failing on little-endian. There is also another test that's failing on
64-bit little-endian. I will submit a
Eric Botcazou writes:
Yes, the assert is really checking exactly that. Several pieces of
haifa-sched.c assume that the instruction has been recognized during
scheduler initialization to speed up checking if instruction is normal
or some kind of use/clobber/asm.
What happens if an
Eric Botcazou [EMAIL PROTECTED] writes:
Applying the patch Adam created and posted in the message below resolved
the issue and the compiler successfully bootstrapped:
http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html
Thanks for reporting this. I now can close PR 37424.
There was one reply
Maxim Kuvyrkov writes:
Yes, the assert is really checking exactly that. Several pieces of
haifa-sched.c assume that the instruction has been recognized during
scheduler initialization to speed up checking if instruction is normal
or some kind of use/clobber/asm.
Thanks for the info but I
Maxim Kuvyrkov writes:
I'm not 100% sure about current state of things, considering recent
merge of sel-sched, but before that it was:
set_priorities() - priority() - dep_cost() - recog_memoized().
I don't think that was the case for all insns even before the patch. The only
new thing is
haifa-sched.c:
2302/* Let the target filter the search space. */
2303for (i = 1; i ready-n_ready; i++)
2304 if (!ready_try[i])
2305{
2306 insn = ready_element (ready, i);
2307
2308 gcc_assert (INSN_CODE (insn) = 0
Bingfeng Mei [EMAIL PROTECTED] writes:
Both -Dinhibit_libc and -DL_gcov are used as shown in our building log
file. I guess -Dinhibit_libc is added because we used newlibc instead
of glibc. I tried to grep these functions in newlibc and didn't find
them. My question is how to enable gcov
XU SHENG [EMAIL PROTECTED] writes:
int priv_dat __attribute__ ((section(.note))) = MAGIC;
...
It's clear to me that only section marked attribute with the
startup of .note can be compiled to section with type SHT_NOTE in ELF
file. Then only problem is assembler in gcc assumed
Matt Lee writes:
In any case, I am trying to optimize the case where there is clearly no
aliasing. Your suggestion regarding movmemsi is interesting. I have not used
this pattern before and assumed that it was required only when something
special must be done to do block moves. In my
Matt Lee [EMAIL PROTECTED] writes:
I am seeing poor scheduling in Dhrystone where a memcpy call is
expanded inline.
memcpy (dst, src, 16) ==
load 1, rA + 4
store 1, rB + 4
load 2, rA + 8
store 2, rB + 8
...
Are you sure that there are no dependencies due to aliasing here. The
only
Sandra Loosemore [EMAIL PROTECTED] writes:
#6 0x0875dc03 in rest_of_handle_combine ()
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/combine.c:1264
...
Looks like a job for valgrind? But I'm out of time for working on
this, at least for now. Can anyone else take a stab at it?
Richard Kenner writes:
I am glad to see we are converging toward implementation issues now!
I am storing it in a new field under the alias_set_entry:
get_alias_set_entry (TYPE_ALIAS_SET (t))-nonaddr_alias_set.
Where T is which type?
Type of the expression passed to
Eric Botcazou writes:
For the Ada testcase:
;; s-i = 0
(insn 7 6 0 p.adb:5 (set (mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 variable.i+0
S4 A32])
(const_int 0 [0x0])) -1 (nil))
;; *p = 1
(insn 8 7 0 p.adb:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [2 S4 A32])
(const_int 1 [0x1]))
get_alias_set and internally record_component_aliases makes
assumptions about the IR that are only valid in RTL. As a consequence
the constant 1 is propagated into the function call in the example
below (I found this issue with 4.1 but it is also present on trunk):
struct s
{
long long
Daniel Berlin writes:
On 6/15/07, Adam Nemet [EMAIL PROTECTED] wrote:
get_alias_set and internally record_component_aliases makes
assumptions about the IR that are only valid in RTL.
What is this assumption, exactly?
That non-addressable fields are always accessed through alias set 0
Ben Elliston [EMAIL PROTECTED] writes:
I see a couple of solutions, but would like to discuss them here before
working on a patch:
1. have the bprob.exp test driver create the appropriate directory
tree on the target (and remove it when finished); or
2. set GCOV_PREFIX when running the
Jim Wilson writes:
Yes, it looks like fixing the combiner problem would make it possible to
remove the mistaken mode checks.
Thanks very much, Jim. I will work toward removing these then.
Adam
Hi,
I am trying to understand why the MIPS backend's handling of
comparison modes seems to be different from what rtl.texi says:
The mode of the comparison operation is independent of the mode
of the data being compared. If the comparison operation is being tested
(e.g., the first operand
68 matches
Mail list logo
