Announcement: gdfa - Generic data flow analyzer for GCC.
Developed by: GCC resource center, IITB
Patch and the Documentation can be found at the below link,
http://www.cse.iitb.ac.in/grc/gdfa.html
Ms. Seema S. Ravandale
Project Engg,
GCC Resource Center
Department of Computer Science & Engg.
II
To solve the above issue, can I use the "define_peephole2" insn pattern?
No. At most you could abuse it to hide the issue some of the time.
You probably have one or more of your target macros / hooks wrong,
e.g. HARD_REGNO_NREGS.
Thank you very much for your reply. In my case, code generation
2009/3/2 daniel tian :
> 2009/2/27 daniel tian :
>> 2009/2/27 Dave Korn :
>>> daniel tian wrote:
>>>
That seems to solving a address mode problem. My problem is that while
loading a large immediate data or SYMBOL_REF, the destination is a
specified general register (register 0:R0).
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 expressions.
See http://gc
"Bingfeng Mei" writes:
> #define A 255
>
> int tst1(short a, short b){
> if(a > (b - A))
> return 0;
> else
> return 1;
>
> }
>
>
> int tst2(short a, short b){
> short c = b - A;
> if(a > c)
> return 0;
> else
> return 1;
>
> }
These computations are different. As
Should I file a bug report? If it is not a C semantics thing, GCC certainly
produces unnecessarily big code.
.file "tst.c"
.text
.p2align 4,,15
.globl tst1
.type tst1, @function
tst1:
.LFB0:
.cfi_startproc
movswl %si,%esi
movswl %di,%
On Tue, Mar 3, 2009 at 4:06 PM, Bingfeng Mei wrote:
> Hello,
> I came across the following example and their .final_cleanup files. To me,
> both functions should produce the same code. But tst1 function actually
> requires two extra sign_extend instructions compared with tst2. Is this a C
> sem
Hello,
I came across the following example and their .final_cleanup files. To me, both
functions should produce the same code. But tst1 function actually requires two
extra sign_extend instructions compared with tst2. Is this a C semantics thing,
or GCC mis-compile (over-conservatively) in the f
Alex Turjan wrote:
Dear Vladimir,
Not really. There is no requirement for "the units
part of the alternatives of a reservation must belong to the
same automaton". Querying should also work in this
case because function cpu_unit_reservation_p checks all
automata for an unit reservation.
Gcc usage questions should go to the gcc-help mailing list.
Questions about computer architecture should go to another forum,
like comp.arch, but you should check first if they explain
caches, DRAM pages, and memory hierarchies in general in an FAQ.
If you had a constructive proposal how to impr
On Tue, Mar 03, 2009 at 03:44:35PM +0300, Yury Serdyuk wrote:
> So for N multiple of 512 there is very strong drop of performance.
> The question is - why and how to avoid it ?
>
> In fact, given effect is present for any platforms ( Intel Xeon,
> Pentium, AMD Athlon, IBM Power PC)
> and for gcc
To solve the above issue, can I use the "define_peephole2" insn pattern?
No. At most you could abuse it to hide the issue some of the time.
You probably have one or more of your target macros / hooks wrong,
e.g. HARD_REGNO_NREGS.
Any comments or suggestions most welcome.
read and understand
Hi !
I have a simple matrix multiplication code:
#include
#include
#include
main ( int argc, char *argv[] )
{
int i, j, k;
clock_t t1, t2;
double elapsed_time;
intN = 10;
float *a, *b, *c;
if ( argc > 1 )
N = atoi ( argv [ 1 ] );
a = (float *) malloc ( N * N * sizeof ( float ) );
Hello,
I have ported gcc to a 16-bit target. Now problem is, gcc generates wrong code
with -O1 and above optimization for move and load/store instructions, b using
the 32-bit registers with 16-bit instructions. For ex:
===
move r13, r1 // move 0-15 bit to r1 register
move r13, r0 // move 16-31
Seema Ravandale wrote:
> Hi.
>
> Given a function pointer in GIMPLE IR, is there any way to find
> address/offset to which function pointd to?
>
> e.g. I have written a code,
> /** C code **/
> void foo()
> {
> . . . .
> }
>
> void (*fptr)(void) = foo;
>
> int main()
> {
> . . . . .
> }
>
Hi.
Given a function pointer in GIMPLE IR, is there any way to find
address/offset to which function pointd to?
e.g. I have written a code,
/** C code **/
void foo()
{
. . . .
}
void (*fptr)(void) = foo;
int main()
{
. . . . .
}
GIMPLE tree node for fptr would be, VAR_DECL--*-->
POINTER_T
16 matches
Mail list logo
