This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix several endless loops in cse_insn for certain target types combinations


Ian Lance Taylor <ian@airs.com> writes:
> Igor Shevlyakov <igor@microunity.com> writes:
>> >Another approach would be for you to put
>> >
>> >INT_MODE (OI, 32);
>> >
>> >in your CPU-modes.def file, and to patch genmodes.c to add something
>> >like
>> >    gcc_assert (BITS_PER_WORD < GET_MODE_BITSIZE (MAX_MODE_INT));
>> >to init_adjust_machine_modes.
>> >
>> >The main advantage of this, if it works, would be keeping the code
>> >slightly simpler for the ordinary case.
>> >
>> 
>> But that means to introduce fake type, I didn't plan to use. This will
>> require to add several new patterns into .md file  (at least movoi),
>> handle calling convention for OI type and god knows what else.
>
> No, defining a new mode does not require you to actually handle it
> anywhere, any more than the fact that TImode exists by default
> requires any backend to handle it.
...

>> But even in general, to have a code which could loop endlessly and
>> pass a knowledge that "in order for compiler to work, you always need
>> to define types with 2*BITS_PER_WORD size", looks like not very wise
>> maintainance policy to me.
>
> That's why I recommended having init_adjust_machine_modes verify that
> the assumptions were met, so nobody else would encounter the problem
> which you encountered.
...

> Well, I can't approve the patch anyhow.  You should probably see what
> an appropriate maintainer thinks.

My opinion, for what it's worth, is that the cost of doing an
additional check in those loops in cse.c ought to be in the noise, and
that it's worth it to avoid imposing a weird constraint like this on
back-ends, even if it were enforced in init_adjust_machine_modes as
you suggest.

I could theoretically approve Igor's original patch, but I don't know
from cse.c, so would prefer to let Roger or Richard or someone weigh
in.

zw

p.s. Igor, has Microunity filed copyright assignment paperwork with
the FSF for this new port, and more generally, for patches developed
on their dime?  If not, it would be wise to start that process now.
I encourage you also to file a personal copyright assignment; then we
can give you CVS write-after-approval without worrying about what
happens if and when you change jobs.  Write fsf-records@gnu.org for
instructions.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]