Hello,
as a result of my decision to leave STMicroelectronics by the end of the
month, I'm stepping down as the maintainer of the st/cli development
branch (the home of the CLI back-end).
In my next job, I will be working in quite a different field; I already
know it won't be compatible with a
Zdenek Dvorak wrote:
Hello,
In principle, I don't see anything forbidding Zdenek's idea.
Unfortunately, what I avoided to mention is that TARGET_MEM_REF nodes
are also transformed into pointer arithmetics
and the equivalent
INDIRECT_REF memory access... therefore, this is not an option even o
Zdenek Dvorak wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs
Zdenek Dvorak wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs
Hello,
I've got a question for experts of alias analysis in GCC.
In the CLI back-end of GCC, there is a CLI-specific pass responsible of
some modifications on GIMPLE that simplify the emission of CIL bytecode
(see http://gcc.gnu.org/projects/cli.html#internals for more details).
One of such mod
Andrew Haley wrote:
Roberto COSTA writes:
> Andrew Haley wrote:
> > Chris Jefferson writes:
> >
> > > One thing which comes up regularly in various C and C++
> > > messageboards is that statements like "f() + g()" and "a(f(), g())"
Andrew Haley wrote:
Chris Jefferson writes:
> One thing which comes up regularly in various C and C++
> messageboards is that statements like "f() + g()" and "a(f(), g())"
> do not declare which order f() and g() will be executed in.
>
> How hard would it be to fix the order of execution i
Hello,
the message is off-topic here (this is a list about GCC development),
but the answer to your question is easy and short: you should write your
program in C.
Cheers,
Roberto
[EMAIL PROTECTED] wrote:
Hello,
I have a RCM3400 Rabbitcore and I must create a client with this
circuit. I ha
Jan Hubicka wrote:
Hello,
CLI back-end uses GIMPLE representation (to be more precise, a subset of
GIMPLE, the code undergoes a CLI-specific GIMPLE lowering at the end of
middle-end passes) and just emits bytecode in a CLI-specific assembler
generation pass.
Because of that, we (I mean CLI bac
Hello,
CLI back-end uses GIMPLE representation (to be more precise, a subset of
GIMPLE, the code undergoes a CLI-specific GIMPLE lowering at the end of
middle-end passes) and just emits bytecode in a CLI-specific assembler
generation pass.
Because of that, we (I mean CLI back-end project) would
u think. I hope it is ready for approval, I'd
really like to check these bits and pieces of work about COND_EXPRs
before I forget about the all matter. :-)
Cheers,
Roberto
2006-11-14 Roberto Costa <[EMAIL PROTECTED]>
* tree-vrp.c (extract_range_from_cond_expr): New.
Roberto COSTA wrote:
Diego Novillo wrote:
Roberto COSTA wrote on 09/28/06 05:51:
If time allows me, I'd like to try to see what happens if COND_EXPRs
are kept throughout the GIMPLE passes (I confess I'm curious).
Logically, I see them as richer constructs (they carry more
inform
Diego Novillo wrote:
Roberto COSTA wrote on 09/28/06 05:51:
If time allows me, I'd like to try to see what happens if COND_EXPRs are
kept throughout the GIMPLE passes (I confess I'm curious). Logically, I
see them as richer constructs (they carry more information than the
equivale
Paolo Bonzini wrote:
Yes. This is also true for a few other expressions. IIRC, the
gimplifier expands MAX_EXPR into control flow, even though it is legal
gimple.
In fact it did this, but later it was removed from the gimplifier
because it generated worse code.
The usual reason for this
Daniel Berlin wrote:
On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello,
I have a question about the form of COND_EXPR nodes allowed in GIMPLE
representation.
By looking at what gimplify.c does (more precisely, at function
gimplify_cond_expr (...) ), I understood that GIMPL
Hello,
I have a question about the form of COND_EXPR nodes allowed in GIMPLE
representation.
By looking at what gimplify.c does (more precisely, at function
gimplify_cond_expr (...) ), I understood that GIMPLE only allows a
restricted form of COND_EXPR, in which both 'then' and 'else' operands
wrote:
Hi Roberto,
On Thu, 7 Sep 2006, Roberto COSTA wrote:
following previous discussions in this mailing list and the approval
from RMS and the steering committee about a CLI port of gcc, I've opened
a development branch to host its development. The branch is st/cli.
would you mind a
Hello,
following previous discussions in this mailing list and the approval
from RMS and the steering committee about a CLI port of gcc, I've opened
a development branch to host its development. The branch is st/cli.
The CLI port project aims at producing highly-optimized CIL binaries,
compli
Andrew Pinski wrote:
On Jul 14, 2006, at 11:01 PM, Roberto COSTA wrote:
Is it a bug... or am I trying to do something wrong?
Why are you trying to regimplify something which is in gimple?
I'm trying to generate new code, which happens to contain TARGET_MEM_REF.
To do that, I find
Hello,
I've just noticed that gimplify_expr () function (from gimplify.c)
asserts when trying to gimplify a TARGET_MEM_REF.
TARGET_MEM_REF nodes are generated after the gimplification pass, this
is why gimple_expr (...) doesn't expect any TARGET_MEM_REF at all.
However, gimplify_to_stmt_list
Hello,
last week I announced that, within the R&D division of
STMicroelectronics I belong to, my team decided to work about a CIL
back-end for gcc (see http://gcc.gnu.org/ml/gcc/2006-06/msg00420.html).
After receiving positive feedback and interest about such a back-end, I
thought it's a good i
Hello Manuel,
three people may have given witty replies... isn't a smile worth that?
I'm also new to the list, and I respect it as a place for meaningful
discussions. At the same time, I'm not against any genuine and
spontaneous humour that may arise from time to time among such serious
matters
Gunnar Sjoo wrote:
According to your proposal, I hereby send my comments referring to your web
pages about downloading gcc. To me, your instructions are absolutely
impossible to understand, they could not be more impossible to understand if
they were written in Hebroe or Mandarin.
I will
Ori Bernstein wrote:
On Mon, 12 Jun 2006 09:50:13 +0200, Roberto COSTA <[EMAIL PROTECTED]> said:
Hello,
I'm working for an R&D organization of STMicroelectronics. Within our
team we have decided to write a gcc back-end that produces CIL binaries
(compliant with ECMA spe
Diego Novillo wrote:
Sebastian Pop wrote on 06/12/06 12:40:
This page has no discussion about a CIL backend.
Note that I never said 'CIL'. I specifically said 'bytecode
representation'. The work being done for LTO will have some points in
common with an effort to build a CIL backend.
Th
Hello,
I'm working for an R&D organization of STMicroelectronics. Within our
team we have decided to write a gcc back-end that produces CIL binaries
(compliant with ECMA specification, see
http://www.ecma-international.org/publications/standards/Ecma-335.htm).
Our main motivation is the abili
26 matches
Mail list logo
