This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: cfgexpand.c patch for msp430-elf
- From: Mike Stump <mikestump at comcast dot net>
- To: Jeff Law <law at redhat dot com>
- Cc: DJ Delorie <dj at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 17 Jul 2013 13:38:59 -0700
- Subject: Re: cfgexpand.c patch for msp430-elf
- References: <51E6F701 dot 2040305 at redhat dot com>
On Jul 17, 2013, at 12:56 PM, Jeff Law <law@redhat.com> wrote:
> Sorry, I must have missed this as being a partial integer issue.
>
> The partial integer modes have the same size/precision as their normal sized cousins in terms of GCC's representation.
In our compiler, we push forward the precision from the target to the data structure for modes (aka mode_precision), and certainly the precision is precisely known and exact. There is nothing wrong with gcc knowing this value and indeed my contention is all machines with partial int modes well know the actual width. My claim is that the entire compiler respects the precision of the mode and does the right thing with it, and it need not be the same at the mode for which the partial mode is backed by.
> However, they also have a target dependent implicit precision which is not exposed to GCC.
Likewise.
> PSI modes have always been implemented this way -- I did a PSImode target back in 1997 or so.
Ours is not. We can have a P18SI mode, and it is different from a P1SI mode, and is known to have 18 bits of precision. The existing code is very good about using the stated precision and if that precision is less than the precision of the mode for which the mode is partial of, doing the right thing.
> I can't comment on the FRACTIONAL modes as they didn't exist when I had to do the mn102 port.
Yeah, likewise, we tried other methods, and PARTIAL_INT turned out to be the best fit.
Once we get done with the wide-int stuff, I'd like to contribute the partial int modes work. It truly is very, very small and light weight.