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 runni
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
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
Jean Christophe Beyler 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 rtx costs function
>
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") )
> (const_int 8 [0x8] 71 {movdi_
Markus L 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 address beeing
> ca
"Charles J. Tabony" 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
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
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 b
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 y
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.
&
Diego Novillo 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:
http://gcc.gnu.org/ml/gcc-
Paul Brook 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 useless for a
fanqifei 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 style affect it?
fanqifei writes:
> 2010/1/18 Adam Nemet :
> > 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 ha
Ian Lance Taylor writes:
> Mat Hostetter 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)) == SIGN_EXTEND)
>> ret
Mat Hostetter writes:
> Adam Nemet writes:
>
> > Ian Lance Taylor writes:
> > > Mat Hostetter writes:
> > >
> > >> Since the high bits are already zero, that would be less efficient on
> > >> most platforms, so guarding it wit
Jean Christophe Beyler 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)
> (zero_extract:DI
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 ()
{
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
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 undocume
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, t
Gerald Pfeifer writes:
> +January 27, 2008
2009 ;)
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
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
Yoriko Komatsuzaki 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 performance issues.
Th
Bernd Schmidt 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))
...
(set (REGX) (CONST_INT
"Rahul Kharche" 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 constants wi
Adam Nemet 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
Thanks for measuring these.
Laurent GUERBY 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 checked (on Octeon)
Steven Bosscher writes:
> On Sun, Mar 15, 2009 at 11:19 PM, Ramana Radhakrishnan
> 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 once in a while, all targets
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 t
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.
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 ancho
Richard Sandiford writes:
> Adam Nemet 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.
Richard Sandiford writes:
> Adam Nemet 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.
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) (cons
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 chang
Adam Nemet 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 there w
Adam Nemet 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 for example
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
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"
> : "=a0" (error): "a0" (path), "a1" (name), "a2" (
Jamie Prescott writes:
> > From: Adam Nemet
> > Jamie Prescott writes:
> > > static inline int set_prop(char const *path, char const *name,
> > > void const *data, int size)
> > > {
> > > int error
Steven Bosscher 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
> , but I can't figure out how to get the REG for
> new_regno without remembering a pointer to it myself. Is there an
> easier/better way?
reg
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 t
Revital1 Eres 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' expe
Andrew Haley 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 don't think t
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 w
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 lin
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
Ian Lance Taylor 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.
With GMP 4.
Ian Lance Taylor 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.
MIPS bootst
"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 g
"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 g
agreed with MTI
> beforehand (although I hadn't realised MTI themselves had written
> the specification). Having thought it over, I think it would be best
> if I stand down as a MIPS maintainer and if someone with the appropriate
> commercial connections is appointed instead. I&#
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
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
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 thin
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 w
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
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
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 a:
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 al
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 .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]))
Richard Kenner writes:
> But there's also an implementation issue: where do you propose to *store*
> this fake alias set? There is no such field as DECL_ALIAS_SET.
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:
ge
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 g
Richard Kenner writes:
> Otherwise, if you have
>
> struct foo {int a: 32; int b: 32; };
> struct bar {int c: 32; int d: 32; };
>
> you have the fields A and C conflicting, which is wrong.
Well, that is where structure-field aliasing comes in. The two cannot
even alias for addressab
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
"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 h
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 archit
72 matches
Mail list logo
