Bring more pleasure to your xlife! http://pdo.
>> In ELF you have to think about symbol overriding. Let's say you link
>> a.o b.o c.o. a.o has a reference to symbol S. b.o has a strong
>> definition. c.o has a weak definition. a.o and c.o have LTO
>> information, b.o does not. ELF requires that a.o call the symbol from
>> b.o, not the sym
> Hi,
>
> setup_incoming_varargs_64 in i386.c has
>
> /* Compute address to jump to :
> label - 5*eax + nnamed_sse_arguments*5 */
>
> The comments don't match the code. Shout the comments be
>
> /* Compute address to jump to :
> label - 4*eax + nnamed_sse_arguments
> Jan Hubicka wrote:
>
> >Sure if it works, we should be lowering the types during gimplification
> >so we don't need to store all this in memory...
> >But C++ FE still use its local data later in stuff like thunks, but we
> >will need to cgraphize them anyway.
>
> I agree. The only use of langu
Hello All
As (I imagine) many developers I have a 64 bits machine - running Debian
(Sid) Linux AMD64.
I want to test my MELT branch on x86 (32 bits). So I set up (using
debootstrap) a x86 32 bits Debian/Lenny chroot-ed system (in /debian32)
which has most of the *-dev packages installed.
I
Basile STARYNKEVITCH wrote:
> Hello All
>
> As (I imagine) many developers I have a 64 bits machine - running Debian
> (Sid) Linux AMD64.
>
> I want to test my MELT branch on x86 (32 bits). So I set up (using
> debootstrap) a x86 32 bits Debian/Lenny chroot-ed system (in /debian32)
> which has mo
On Thu, Jun 5, 2008 at 3:14 PM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Hello All
>
> As (I imagine) many developers I have a 64 bits machine - running Debian
> (Sid) Linux AMD64.
>
> I want to test my MELT branch on x86 (32 bits). So I set up (using
> debootstrap) a x86 32 bits Debian/Le
"Rafael Espindola" <[EMAIL PROTECTED]> writes:
> Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
> of the opposite of what I had understood. What do you do in this case:
>
> a.o: IL file that contains a reference to "f"
> b.o: IL file that has a weak def of "f"
>
> There is no
Chris Lattner <[EMAIL PROTECTED]> writes:
> I don't know how closely your plans follow this model. If you think
> this approach is reasonable, you really do need to reflect things like
> symbol versions in your IR somehow. This compiler must know about
> versions, and when it does, it is easy to
Hi,
x86-64 psABI defines
typedef struct
{
unsigned int gp_offset;
unsigned int fp_offset;
void *overflow_arg_area;
void *reg_save_area;
} va_list[1];
for variable argument list. "va_list" is used to access variable argument
list:
void
bar (const char *format, va_list ap)
{
if (va_arg
On Thu, Jun 5, 2008 at 4:31 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> x86-64 psABI defines
>
> typedef struct
> {
> unsigned int gp_offset;
> unsigned int fp_offset;
> void *overflow_arg_area;
> void *reg_save_area;
> } va_list[1];
>
> for variable argument list. "va_list" is used to acc
Hi,
I am jumping in somewhat late, as yesterday I was on meetings without
internet access. (and I probably will be offline again tomorrow)
I think that in basic terms we all mostly agree (we want to implement
optimization scheme that does not get everything into memory, we want to
parallelize the
>
> 1. Extend the register save area to put upper 128bit at the end.
> Pros:
> Aligned access.
> Save stack space if 256bit registers are used.
> Cons
> Split access. Require more split access beyond 256bit.
>
> 2. Extend the register save area to put full 265bit YMMs at the end.
On Thu, Jun 5, 2008 at 11:09, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> I think one problem is that both repackaging and cherry picking as
> described is very centric about application on inlining.
No, that's simply the main application for the initial implementation.
Any other summary-based tran
On Thu, Jun 5, 2008 at 7:49 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 4:31 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> x86-64 psABI defines
>>
>> typedef struct
>> {
>> unsigned int gp_offset;
>> unsigned int fp_offset;
>> void *overflow_arg_area;
>> void
On Thu, Jun 5, 2008 at 8:15 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>>
>> 1. Extend the register save area to put upper 128bit at the end.
>> Pros:
>> Aligned access.
>> Save stack space if 256bit registers are used.
>> Cons
>> Split access. Require more split access beyond 256bi
On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
I don't know how closely your plans follow this model. If you think
this approach is reasonable, you really do need to reflect things
like
symbol versions in your IR somehow. This compiler must
On Jun 5, 2008, at 6:59 AM, Ian Lance Taylor wrote:
"Rafael Espindola" <[EMAIL PROTECTED]> writes:
Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
of the opposite of what I had understood. What do you do in this
case:
a.o: IL file that contains a reference to "f"
b.o:
On Sat, May 03, 2008 at 08:29:25AM -0400, Doug Gregor wrote:
> INNERMOST_TEMPLATE_ARGS can be used to get at the "innermost" TREE_VEC
> of template arguments for a class template specialzation such as
> foo::bar. CLASSTYPE_USE_TEMPLATE != 0 tells you whether a
> RECORD_TYPE is actually a template
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:
>
>> Chris Lattner <[EMAIL PROTECTED]> writes:
>>
>>> I don't know how closely your plans follow this model. If you think
>>> this approach is reasonable, you really do need to reflect things
>>> like
Chris Lattner <[EMAIL PROTECTED]> writes:
> LLVM LTO handles this by marking symbols "internal" (aka static, aka
> not TREE_PUBLIC, whatever) when the symbol is not visible outside the
> LTO scope. This allows the optimizers to go crazy and hack away at
> the symbols, but only when safe.
How doe
Hello!
1.) The processor_costs structure seems very limited, but seem very
easily to "fill in" but are these costs supposed to be best or worst
case? For instance, many instructions with different sized operands
vary in latency.
Instruction costs are further refined in config/i386.c, ix86_rt
We have code that fails to scale do to the object_mutex lock in
unwind-dw2-fde.c. This mutex protects two lists local to the file. The primary
list is used in "read-mostly" mode, with the secondary list used rarely when
writing needs to happen.
I am trying to change this locking scheme to use
> Luke Dalessandro writes:
Luke> My problem is that unwind-dw2-fde.c seems to be compiled multiple times
during
Luke> a gcc build, and sometimes my additions are found but other times they
are
Luke> not. I am rebuilding again (AIX 5.1), and I'll post more information for
Luke> anyone that
On Jun 5, 2008, at 10:43 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
LLVM LTO handles this by marking symbols "internal" (aka static, aka
not TREE_PUBLIC, whatever) when the symbol is not visible outside the
LTO scope. This allows the optimizers to go crazy and hack
Could you please direct me to someone who would be willing and able to answer a
few questions about some of the internal workings of the gcc compiler.
I am attempting to modify the compiler to instrument function calls and
returns. The end result that i am trying to achieve is to send the addr
On Thu, Jun 05, 2008 at 12:55:17PM -0700, [EMAIL PROTECTED] wrote:
> I am attempting to modify the compiler to instrument function calls and
> returns. The end result that i am trying to achieve is to send the
> address of every called function to a memory mapped file prior to the
> call and after
Nick Kledzik <[EMAIL PROTECTED]> writes:
>> How does the linker tell LTO that a symbol may be inlined, but must
>> also be externally visible?
> The linker just tells LTO which symbols must remain. The LTO engine
> is free to inline anything that would improve codegen, with the
> exception
> that
Basile STARYNKEVITCH writes:
> Hello All
>
> As (I imagine) many developers I have a 64 bits machine - running Debian
> (Sid) Linux AMD64.
>
> I want to test my MELT branch on x86 (32 bits). So I set up (using
> debootstrap) a x86 32 bits Debian/Lenny chroot-ed system (in /debian32)
> which ha
On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote:
Nick Kledzik <[EMAIL PROTECTED]> writes:
How does the linker tell LTO that a symbol may be inlined, but must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO engine
is free to inline anything that wo
David Edelsohn wrote:
Luke Dalessandro writes:
Luke> My problem is that unwind-dw2-fde.c seems to be compiled multiple times during
Luke> a gcc build, and sometimes my additions are found but other times they are
Luke> not. I am rebuilding again (AIX 5.1), and I'll post more information for
Snapshot gcc-4.3-20080605 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080605/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> Luke Dalessandro writes:
Luke> Thank you, this was indeed the problem. I added the needed stubbs in
Luke> gthr-single.h and it now compiles fine. Unfortunately there seems to be
Luke> something wrong with my installation of ld as linking fails with a large
Luke> number of errors of the fo
On Thu, Jun 5, 2008 at 5:57 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>> Jan Hubicka wrote:
>>
>> >Sure if it works, we should be lowering the types during gimplification
>> >so we don't need to store all this in memory...
>> >But C++ FE still use its local data later in stuff like thunks, but we
David Edelsohn wrote:
Luke Dalessandro writes:
Luke> Thank you, this was indeed the problem. I added the needed stubbs in
Luke> gthr-single.h and it now compiles fine. Unfortunately there seems to be
Luke> something wrong with my installation of ld as linking fails with a large
Luke> number
A small request.
Can the md5 sum hash for the various release files be published at the
main GCC release pages ?
If we look at http://gcc.gnu.org/gcc-4.2/ there is no md5 sum there
and while I can find that data at a mirror thus :
ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/relea
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote:
>
>> Nick Kledzik <[EMAIL PROTECTED]> writes:
>>
How does the linker tell LTO that a symbol may be inlined, but must
also be externally visible?
>>> The linker just tells LTO which symbols mus
On Fri, Jun 06, 2008 at 01:03:19AM +, Dennis Clarke wrote:
> Can the md5 sum hash for the various release files be published at the
> main GCC release pages ?
> If we look at http://gcc.gnu.org/gcc-4.2/ there is no md5 sum there
> and while I can find that data at a mirror thus :
>
> ftp://ftp
38 matches
Mail list logo
