On 15 June 2010 04:03, Diego Novillo wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. In particular, the front ends
> should make use of it and the callgraph mana
Quoting Manuel López-Ibáñez :
I would think that instead of hooks, a program should be able to call
pass_manager functions to query/add/remove/reorder passes within a
running program. That is, make the pass_manager a library that works
on passes. GCC would just call that library to implement its
On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
wrote:
>
> Every hardcoded reference to a mode other than QImode in the
> target-independent compiler is suspicious and needs investigating if you
> are doing such a port. In this case, the SImode references in
> expand_float are likely the problem
On Mon, Jun 14, 2010 at 7:01 PM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> In gcc4.3.4, for my architecture: 16 BITS_PER_UNIT, 1 UNIT_PER_WORD,
>> with INT_TYPE_SIZE = 16 and FLOAT_TYPE_SIZE = 32, then an unsigned int
>> is QImode and a float is HFmode.
>>
>> However with:
>> float
On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. In particular, the front ends
> should make use of it and the call
On Tue, Jun 15, 2010 at 9:17 AM, Paulo J. Matos wrote:
> On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
> wrote:
>>
>> Every hardcoded reference to a mode other than QImode in the
>> target-independent compiler is suspicious and needs investigating if you
>> are doing such a port. In this case
On Tue, Jun 15, 2010 at 9:17 AM, Paulo J. Matos wrote:
> On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
> wrote:
>>
>> Every hardcoded reference to a mode other than QImode in the
>> target-independent compiler is suspicious and needs investigating if you
>> are doing such a port. In this case
Hi,
I want to limit the size of immediate field of some operation. For example
somehow modify the machine description that the compiler supports only 0-255
for immediate operand.
I also want to change the compiler to the 2-address operand.
do you have any ideas?
I just need some hint
Best Regard
Hello All,
I am in the process of merging 4.6 (i.e. current trunk) into the GCC
MELT branch. However, I want very much the same source code to be able
to run as a plugin to 4.5 & as a plugin to 4.6. So precisely, I want
to have gcc/melt-runtime.c from the MELT branch compilable as a plugin
melt.so
Hello,
> I want to limit the size of immediate field of some operation.
I think you can look at SIGNED_INT_FITS_N_BITS definition at
config/crx/crx.c
for such example.
You can write a predicate like the following; and use it when describing
the immediate
operand in the md file.
(define_predicate
On Tue, 15 Jun 2010, Paulo J. Matos wrote:
> This comment provides some insight on to why gcc keeps converting to
> SImode. However, I think (and it is at least applicable to my case)
> that it should convert to QImode and if there are no libraries, tell
> the implementor of the backend to provid
On Tue, Jun 15, 2010 at 11:26 AM, Basile Starynkevitch
wrote:
> Hello All,
>
> I am in the process of merging 4.6 (i.e. current trunk) into the GCC
> MELT branch. However, I want very much the same source code to be able
> to run as a plugin to 4.5 & as a plugin to 4.6. So precisely, I want
> to h
Quoting Basile Starynkevitch :
A small but annoying issue is that GCC 4.5's gengtype does not accept
the variable_size annotation, and I would want to have it ignore
it. As far as I know, gengtype don't like CPP conditionals;
You can have a separate Makefile rule generate a header file without
Quoting "Joseph S. Myers" :
For targets with 8-bit bytes and 32-bit registers (and without hardware
floating point), there is probably no point in having most conversion
functions to/from QImode or HImode separate from those to/from SImode, as
they likely wouldn't be any more efficient so would
On Tue, Jun 15, 2010 at 10:42 AM, Joseph S. Myers
wrote:
> On Tue, 15 Jun 2010, Paulo J. Matos wrote:
>
> For targets with 8-bit bytes and 32-bit registers (and without hardware
> floating point), there is probably no point in having most conversion
> functions to/from QImode or HImode separate fr
On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke wrote:
>
> I think it is also a reflection of an 'all the world is (at least) 32 bit'
> attitude - in part supported by the GNU coding standard as it was then
> aimed at making an easily maintainable workstation / server operating
> system.
> I.e. t
Quoting "Paulo J. Matos" :
On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke wrote:
I think it is also a reflection of an 'all the world is (at least) 32 bit'
attitude - in part supported by the GNU coding standard as it was then
aimed at making an easily maintainable workstation / server oper
Hi,
I'm working with GCC 2.7. I think, It doesn't support define_predict.
I define a c function in the mips.c file and add the following lines:
int
new_arith_operand (op, mode)
rtx op;
enum machine_mode mode;
{
if (GET_CODE (op) == CONST_INT)
if(NEW_INT_UNSIGNED (op))
On 15 June 2010 14:01, yazdanbakhsh wrote:
>
> I'm working with GCC 2.7. I think, It doesn't support define_predict.
> I define a c function in the mips.c file and add the following lines:
[...]
> I appreciate any help.
I think the best advice I can give you is: Use a recent GCC version.
GCC 2.7
On Tue, Jun 15, 2010 at 1:00 PM, Joern Rennecke wrote:
> Quoting "Paulo J. Matos" :
>
>> On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke
>> wrote:
>>>
>>> I think it is also a reflection of an 'all the world is (at least) 32
>>> bit'
>>> attitude - in part supported by the GNU coding standard as
Actually, I'm working with simplescalar and it only supports gcc 2.9.
--
View this message in context:
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28890565.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Hi,
On Tue, 15 Jun 2010, Paulo J. Matos wrote:
> >> Is GCC slowly losing support for certain archs or it is still
> >> striving to be as generic as possible?
> >
> > GCC looses and gains support for architectures depending on the
> > availability of competent volunteer maintainers for these
>
Hi all,
I am implementing some function for conversion between modes (QI ->
HF, SF -> HI, etc). For this it would be useful to know the floating
point representation using in libgcc. However, I can't find any
description of it anywhere. Is it using IEEE floating point
representation?
Cheers,
--
2010/6/15 Basile Starynkevitch :
> /*** NOTE: june 2010.
>
> GCC 4.6 has a new typed garbage collected allocator; so any
> GTY-ed struct FOO_ST should be allocated using ggc_alloc_FOO_ST
> or ggc_alloc_cleared_FOO_ST.
> ***/
> #if BUILDING_GCC_VERSION >= 4006 && defined(g
Quoting "Paulo J. Matos" :
Hi all,
I am implementing some function for conversion between modes (QI ->
HF, SF -> HI, etc). For this it would be useful to know the floating
point representation using in libgcc. However, I can't find any
description of it anywhere. Is it using IEEE floating point
"Amker.Cheng" writes:
> here are three more questions
> 1 , If I am talking the right thing, there are two insns like
>"*mulsi3_1" and "*smulsi3_highpart_insn",
> which set two parts of DImode pseudo regs of DImode mult.
>
> Since both parts pf result are used in the original
Jeff Law writes:
> Note that lower-subreg is rather conservative when determining what
> subregs to lower, particularly when the pseudo appears in different
> modes (ie, some accesses are via SUBREGs, others are naked REGs). So
> this approach may not necessarily work.
Right; it only works if a
On 06/13/2010 03:09 PM, Gerald Pfeifer wrote:
> On Mon, 7 Jun 2010, Tobias Burnus wrote:
>
>>> It has been reported via the FSF that 'gfortran.info' is copyrighted by
>>> the FSF '1999-2008', although it should be under the form '1999, 2000,
>>> [other years], 2008'.
>>>
>> Fixed in Rev
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. In particular, the front ends
> should make use of it and the callgraph manager, instead of the
> twisted interactions we
On Tue, 2010-06-15 at 14:56 +0200, Laurynas Biveinis wrote:
> I'd say, use a common ggc_alloc_cleared_meltobject_st which is made by
> gengtype in 4.6+ and provide its suitable definition yourself for 4.5.
Thanks for the good advice.
BTW, I only want if possible MELT to work for 4.5 & 4.6, and "w
On Tue, 2010-06-15 at 18:38 +0200, Jan Hubicka wrote:
Citing Diego Novillo:
> > I have been thinking about doing some cleanups to the pass manager.
> This has been my goal for years, but somehow it always got off the top of
> TODO list ;)
> >
> > Additionally, I would like to (at some point) inc
Bernd Schmidt wrote:
> On 06/15/2010 12:06 AM, Ian Lance Taylor wrote:
> > Well, as you know, subregs have two meanings which look similar but
> > are in fact entirely different. It's valid to set subregs of the same
> > pseudo in parallel if the subregs represent different hard registers.
> > It'
yazdanbakhsh writes:
> I'm working with GCC 2.7.
I think I see your problem.
> I think, It doesn't support define_predict.
> I define a c function in the mips.c file and add the following lines:
>
> int
> new_arith_operand (op, mode)
> rtx op;
> enum machine_mode mode;
> {
> if (GE
On 15 June 2010 10:40, Richard Guenther wrote:
> On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo wrote:
>
>> - Pass scheduling can be done by simply declaring a pass and
>> presenting it to the pass manager. The property sets should be enough
>> for the PM to know where to schedule a pass.
>
> Ug
Quoting Basile Starynkevitch :
I believe that a structured comment could help. When - in many
years :-( - the powerful people (Steering Committee, FSF, RMS, ...)
would accept the idea of generating documentation from code [and
implement the legalese allowing it thru appropriate exceptions, or le
On Tue, 2010-06-15 at 13:28 +0100, Paulo J. Matos wrote:
> Hi all,
>
> I am implementing some function for conversion between modes (QI ->
> HF, SF -> HI, etc). For this it would be useful to know the floating
> point representation using in libgcc. However, I can't find any
> description of it an
Snapshot gcc-4.4-20100615 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100615/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I can no longer make check ins to the gcc repository, it's been a few
months since my last check in, which worked fine.
I get:
ssh: connect to host gcc.gnu.org port 22: Connection refused
svn: Connection closed unexpectedly
anonymouse access works fine.
I'm "r...@gcc.gnu.org"
If someone cou
On 16/06/2010 02:08, Douglas B Rupp wrote:
>
> I can no longer make check ins to the gcc repository, it's been a few
> months since my last check in, which worked fine.
>
> I get:
> ssh: connect to host gcc.gnu.org port 22: Connection refused
> svn: Connection closed unexpectedly
>
> anonymouse
39 matches
Mail list logo
