On Tue, Dec 18, 2007 at 02:38:31AM -0200, Alexandre Oliva wrote:
> Would reformatting these and stamping a title on top make it worthy of
> your interest?
Actually, I think that *would* help (though, of course, it's impossible
to predict if it would help *enough*).
I've noticed before (though th
On Dec 18, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> Yep. Sometimes code just is optimized away. Can't stop that without
>> harming optimizations.
> OK, so you are agreeing that good debuggability is impossible
> with all the optimizations in place, so once again
Ross, HJ,
>
> >Because I386 PIC requires BX as GOT pointer and I386 may use AX, DX
> >and CX as parameter passing registers, there are limited candidates for
> >this proposal to choose. Current proposal suggests EDI, because it won't
> >conflict with i386 PIC or regparm.
>
> Could you pick a cal
Alexandre Oliva wrote:
Yep. Sometimes code just is optimized away. Can't stop that without
harming optimizations.
OK, so you are agreeing that good debuggability is impossible
with all the optimizations in place, so once again, let's have
an optimziation level that optimizes as far as possib
Alexandre Oliva wrote:
Yes, I've considered something along these lines, but decided against
it, for we can't afford for debug information to affect executable
code generation in any way whatsoever, and we don't want to pessimize
optimized code when compiling without -g just so that compiling wi
On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> Ye, Joey writes:
> >i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
> >and 64 for x86_64. It is the minimum stack boundary. It is fixed.
>
> Strictly speaking by the above definition it would be 8 for i386.
> The h
On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 12/17/07 19:50, Alexandre Oliva wrote:
>> Now, since you're so interested in it and you've already read the
>> various perspectives on the issue that I listed in my yesterday's
>> e-mail to you, would you help me improve this document,
On Dec 17, 2007, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 17, 2007 at 11:11:46PM -0200, Alexandre Oliva wrote:
>> Line number information has a well-defined meaning: it ought to
>> represent the source code line that best represents the source-code
>> construct that ended up implemented u
Ye, Joey writes:
>i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
>and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack to be 32-bit aligned, it just
performs p
-- 0. MOTIVATION --
Some local variables (such as of __m128 type or marked with alignment
attribute) require stack aligned at a boundary larger than the default
stack
boundary. Current GCC partially supports this with limitations. We are
proposing a new design to fully solve the problem.
-- 1. CU
[EMAIL PROTECTED] wrote:
> Are there any comments about the name, semantics, or usefulness of this
> extension?
>
Sounds very useful for SPU code. I look forward to trying it out.
Toying with the idea, the following seems like a potentially useful C++
form of the proposed extension :
struct
On Mon, Dec 17, 2007 at 11:11:46PM -0200, Alexandre Oliva wrote:
> Line number information has a well-defined meaning: it ought to
> represent the source code line that best represents the source-code
> construct that ended up implemented using that instruction.
You implicitly assume that souch a
On Dec 17, 2007, Geert Bosch <[EMAIL PROTECTED]> wrote:
> We could conceptually have inspection points between each source
> statement and declaration, which would roughly correspond to a
> use of all memory and all source variables, wether in memory or
> in registers.
> These inspections points w
On 12/17/07 19:50, Alexandre Oliva wrote:
Now, since you're so interested in it and you've already read the
various perspectives on the issue that I listed in my yesterday's
e-mail to you, would you help me improve this document, by letting me
know what you believe to be missing from the selecte
On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 12/17/07 15:28, Alexandre Oliva wrote:
>>> You need to provide such a document now.
>>
>> Can't I instead provide it when it's ready?
> Of course.
Thanks,
Now, since you're so interested in it and you've already read the
various pe
Hi,
I'm looking for comments on a possible GCC extensions described below.
For the target I'm interested in, Cell SPU, taken branches are only
predicted correctly by explicitly inserting a specific instructions (a
hint instruction) that says "the branch at address A is branching to
address B". T
Snapshot gcc-4.1-20071217 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071217/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 12/17/07 15:28, Alexandre Oliva wrote:
You need to provide such a document now.
Can't I instead provide it when it's ready?
Of course.
Diego.
On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 12/17/07 12:51, Alexandre Oliva wrote:
>> I guess I'm to blame, for having naïvely put the code out without as
>> much as a design and goals document
> Yes, you are.
Wow, thanks. At least we agree on something! ;-)
> You need to p
Hi Rask,
First, Thank you very much for all help you have provided me. It
really help me finish my project.
This is what I did:
I capture all the moves regardless of the operand and then to move an
immediate into a regiser, I force a register:
here is the code for this:
if (!no_n
On Wed, Dec 12, 2007 at 03:35:09PM +0100, 'Rask Ingemann Lambertsen' wrote:
>
>The movxx patterns are special and you'll need to hold the compiler's
> hands a little. Since your target can't move immediates directly to memory,
> you have to ask for a secondary reload to an intermediate registe
On Dec 16, 2007, Joe Buck <[EMAIL PROTECTED]> wrote:
> However, since preserving accurate debug information
> has a cost, I think it would be better to turn -O1, not -O2, into the
> mode that Alexandre wants, where debug information is preserved.
In terms of memory, that's true, it does have a co
On 12/17/07 12:51, Alexandre Oliva wrote:
I guess I'm to blame, for having naïvely put the code out without as
much as a design and goals document
Yes, you are.
You need to provide such a document now. I can't see how you'll be able
to incorporate your implementation without a convincing d
On Dec 16, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>> It is obvious that you misunderstood what I want, and how intrusive
>> the approach is.
> Yes Alexandre, everyone who disagrees with you must not understand!
My conclusion is not based on disagreement, but rather on the faulty
argume
On 12/17/07 02:27, Lijuan Hai wrote:
gcc-4.3-20070912 doesn't allow commas between clauses. Details given
following. I have just scanned c-parser.c and found we could change
c_parser_omp_clause_name () to enable it.
Thanks for the report. Jakub submitted a patch to fix this problem
which I r
gcc-4.3-20070912 doesn't allow commas between clauses. Details given
following. I have just scanned c-parser.c and found we could change
c_parser_omp_clause_name () to enable it. But I want to know more
before making any changes on it myself. "openmp implementation in
gcc" in GCC SUMMIT 2006 seem
26 matches
Mail list logo
