On Tue, Oct 27, 2015 at 12:44 PM, Michael Meissner
wrote:
> This patch adds a test to make sure __float128 and __ibm128 are not allowed to
> be combined in binary operations. I re-ran the test suite on power8 little
> endian, and this test passed. Once the preceeding
On Fri, Oct 23, 2015 at 2:03 PM, Michael Meissner
wrote:
> This patch adds a test to make sure __float128 are passed and returned like
> vector objects, and not as IBM extended double did.
>
> This is the last subpatch of patch #7. I have bootstrapped the compiler
On Fri, Oct 23, 2015 at 1:40 PM, Michael Meissner
wrote:
> This patch sets up all of the emulation functions.
>
> I have built the compiler with this patch and the previous subpatches (1-4).
> I
> have bootstrapped the compiler with all 16 subpatches installed, and
On Fri, Oct 23, 2015 at 1:47 PM, Michael Meissner
wrote:
> This patch is the new patch from the last submission. It sets up a hook so
> that
> the compiler will not allow IBM extended double and IEEE 128-bit floating
> point
> to intermix in a binary expression
On Fri, Oct 23, 2015 at 1:43 PM, Michael Meissner
wrote:
> This patch updates to use the unordered comparison function for IEEE 128-bit
> floating point to mimic the behaviour of SFmode/DFmode using the fcmpu
> instruction.
>
> It also restructures the code to allow a
On Fri, Oct 23, 2015 at 2:01 PM, Michael Meissner
wrote:
> This patch adds the documentation.
>
> I have built the compiler with this patch and the previous subpatches (1-14).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no
On Fri, Oct 23, 2015 at 1:36 PM, Michael Meissner
wrote:
> This patch allows SUBREG's for the reg_or_indexed_operand, which is used when
> you have an integral value in a float/vector register, and you want to move
> the
> value (either via direct move on power8, or
On Fri, Oct 23, 2015 at 2:00 PM, Michael Meissner
wrote:
> This patch makes TFmode be fully switchable for comparisons.
>
> I have built the compiler with this patch and the previous subpatches (1-13).
> I have bootstrapped the compiler with all 16 subpatches
On Fri, Oct 23, 2015 at 1:39 PM, Michael Meissner
wrote:
> This patch prevents the compiler from calling the IEEE 128-bit emulation
> functions with the vector value in both GPRs and vector registers due to the
> fact that the library function did not have a
On Fri, Oct 23, 2015 at 1:30 PM, Michael Meissner
wrote:
> This patch changes the switch from -mfloat128-software and -mfloat128-none to
> be a binary switch, -mfloat128 and -mno-float128. It also provides some of
> the
> basic setup for IEEE types. It also removes
On Fri, Oct 23, 2015 at 1:26 PM, Michael Meissner
wrote:
> This patch is the rs6000.h changes. It makes the IEEE 128-bit floating point
> type that can go in vector registers a 'vector' type, so that the address code
> in rs6000.c that determines whether to use VSX
On Fri, Oct 23, 2015 at 1:52 PM, Michael Meissner
wrote:
> This patch changes the mangling for __float128. I came to the conclusion that
> the current code is so tangled, that it would be better to use U10__float128
> rather than "e". However, if it is felt that we
On Fri, Oct 23, 2015 at 1:58 PM, Michael Meissner
wrote:
> This patch is the second part to allow TFmode to be IBM extended double or
> IEEE
> 128-bit floating point depending on switches.
>
> I have built the compiler with this patch and the previous subpatches
On Fri, Oct 23, 2015 at 1:57 PM, Michael Meissner
wrote:
> This patch is the first of two rs6000.md patches to straighten out the IFmode,
> KFmode, and TFmode support. Part of the change is to change the iterator
> names
> to be easier to understand, using IEEE128,
On Fri, Oct 23, 2015 at 1:33 PM, Michael Meissner
wrote:
> This patch defines 3 macros to tell the user whether -mfloat128 is enabled or
> not, and whether long double is IBM extended double or IEEE 128-bit floating
> point.
>
> I have built the compiler with this
On Fri, Oct 23, 2015 at 1:49 PM, Michael Meissner
wrote:
> This patch is part of the support needed to properly swap IEEE 128-bit
> floating
> point on little endian systems. Note, you will need the rs6000.md changes for
> this to become effective.
>
> I have built
On Fri, Oct 23, 2015 at 1:45 PM, Michael Meissner
wrote:
> This patch adds support for using 'q' or 'Q' as a suffix for __float128
> constants, which is compatible with the existing x86_64 implmenetation of
> their
> __float128 support.
>
> I have built the compiler
On Thu, Oct 29, 2015 at 10:33:48AM -0400, David Edelsohn wrote:
> On Fri, Oct 23, 2015 at 1:40 PM, Michael Meissner
> wrote:
> > This patch sets up all of the emulation functions.
> >
> > I have built the compiler with this patch and the previous subpatches
> >
This patch adds a test to make sure __float128 and __ibm128 are not allowed to
be combined in binary operations. I re-ran the test suite on power8 little
endian, and this test passed. Once the preceeding 16 patches are applied to the
tree, is this patch ok to commit into trunk?
2015-10-27
This patch makes TFmode be fully switchable for comparisons.
I have built the compiler with this patch and the previous subpatches (1-13).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no regressions. Is it ok to install in the trunk?
2015-10-22 Michael
On Fri, Oct 23, 2015 at 01:39:36PM -0400, Michael Meissner wrote:
> This patch prevents the compiler from calling the IEEE 128-bit emulation
> functions with the vector value in both GPRs and vector registers due to the
> fact that the library function did not have a prototype.
>
> I have built
This patch adds a test to make sure __float128 are passed and returned like
vector objects, and not as IBM extended double did.
This is the last subpatch of patch #7. I have bootstrapped the compiler with
all 16 subpatches installed, and there were no regressions. Is it ok to
install in the
This patch is the second part to allow TFmode to be IBM extended double or IEEE
128-bit floating point depending on switches.
I have built the compiler with this patch and the previous subpatches (1-12).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no
This patch changes the switch from -mfloat128-software and -mfloat128-none to
be a binary switch, -mfloat128 and -mno-float128. It also provides some of the
basic setup for IEEE types. It also removes code I had put in a previous patch
that doesn't allow IFmode/KFmode to go in any register if
This patch defines 3 macros to tell the user whether -mfloat128 is enabled or
not, and whether long double is IBM extended double or IEEE 128-bit floating
point.
I have built the compiler with this patch and the previous subpatches (1 and
2). I have bootstrapped the compiler with all 16
This patch prevents the compiler from calling the IEEE 128-bit emulation
functions with the vector value in both GPRs and vector registers due to the
fact that the library function did not have a prototype.
I have built the compiler with this patch and the previous subpatches (1-4). I
have
This patch is part of the support needed to properly swap IEEE 128-bit floating
point on little endian systems. Note, you will need the rs6000.md changes for
this to become effective.
I have built the compiler with this patch and the previous subpatches (1-9). I
have bootstrapped the compiler
David asked me to try and break patch #7 into smaller bite sized chunks. I have
broken this into roughly 16 parts. These are the same patches that I submitted
for patch #7 (revised), just broken up. There is one additional patch in this
selection, to restrict __float128 and IBM extended double
This patch is the first of two rs6000.md patches to straighten out the IFmode,
KFmode, and TFmode support. Part of the change is to change the iterator names
to be easier to understand, using IEEE128, IBM128, and FLOAT128 as the
iterators. This change, and the next change go through and have
This patch is the rs6000.h changes. It makes the IEEE 128-bit floating point
type that can go in vector registers a 'vector' type, so that the address code
in rs6000.c that determines whether to use VSX addressing works. In addition, I
made IEEE 128-bit floating point tie with vectors and not with
This patch allows SUBREG's for the reg_or_indexed_operand, which is used when
you have an integral value in a float/vector register, and you want to move the
value (either via direct move on power8, or via store).
I have built the compiler with this patch and the previous subpatches (1-3). I
This patch sets up all of the emulation functions.
I have built the compiler with this patch and the previous subpatches (1-4). I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions. Is it ok to install in the trunk?
2015-10-22 Michael Meissner
This patch updates to use the unordered comparison function for IEEE 128-bit
floating point to mimic the behaviour of SFmode/DFmode using the fcmpu
instruction.
It also restructures the code to allow a future change to drop in easier.
I have built the compiler with this patch and the previous
This patch is the new patch from the last submission. It sets up a hook so that
the compiler will not allow IBM extended double and IEEE 128-bit floating point
to intermix in a binary expression without using an explicit conversion.
I have built the compiler with this patch and the previous
This patch changes the mangling for __float128. I came to the conclusion that
the current code is so tangled, that it would be better to use U10__float128
rather than "e". However, if it is felt that we should go with "e", I can go
that way as well.
I have built the compiler with this patch and
This patch adds support for using 'q' or 'Q' as a suffix for __float128
constants, which is compatible with the existing x86_64 implmenetation of their
__float128 support.
I have built the compiler with this patch and the previous subpatches (1-7). I
have bootstrapped the compiler with all 16
On Fri, Oct 23, 2015 at 08:05:58PM +, Joseph Myers wrote:
> On Fri, 23 Oct 2015, Michael Meissner wrote:
>
> > This patch is the new patch from the last submission. It sets up a hook so
> > that
> > the compiler will not allow IBM extended double and IEEE 128-bit floating
> > point
> > to
On Fri, Oct 23, 2015 at 01:36:25PM -0400, Michael Meissner wrote:
> This patch allows SUBREG's for the reg_or_indexed_operand, which is used when
> you have an integral value in a float/vector register, and you want to move
> the
> value (either via direct move on power8, or via store).
>
> I
On Fri, Oct 23, 2015 at 01:22:11PM -0400, Michael Meissner wrote:
> David asked me to try and break patch #7 into smaller bite sized chunks. I
> have
> broken this into roughly 16 parts. These are the same patches that I submitted
> for patch #7 (revised), just broken up. There is one additional
On Fri, 23 Oct 2015, Michael Meissner wrote:
> This patch is the new patch from the last submission. It sets up a hook so
> that
> the compiler will not allow IBM extended double and IEEE 128-bit floating
> point
> to intermix in a binary expression without using an explicit conversion.
I
On Fri, Oct 23, 2015 at 02:47:16PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2015 at 01:22:11PM -0400, Michael Meissner wrote:
> > David asked me to try and break patch #7 into smaller bite sized chunks. I
> > have
> > broken this into roughly 16 parts. These are the same patches that I
This patch adds the documentation.
I have built the compiler with this patch and the previous subpatches (1-14).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no regressions. Is it ok to install in the trunk?
2015-10-22 Michael Meissner
On Thu, Oct 08, 2015 at 09:30:45PM +, Joseph Myers wrote:
> Question: what happens if you mix __float128 and __ibm128 in an arithmetic
> or conditional expression?
>
> __float128 a;
> __ibm128 b;
> int x;
> /* ... */
> a + b;
> x ? a : b;
>
> (And likewise if one or both are the
On Tue, 13 Oct 2015, Michael Meissner wrote:
> I believe every non-NaN value that IBM extended double supports is
> representable in IEEE 754R 128-bit floating point, since IEEE has 112 bits of
> mantissa plus the hidden bit, while IBM extended double has 106 bits (52 bits
> of mantissa for each
Question: what happens if you mix __float128 and __ibm128 in an arithmetic
or conditional expression?
__float128 a;
__ibm128 b;
int x;
/* ... */
a + b;
x ? a : b;
(And likewise if one or both are the corresponding complex types.) As I
suggested in
A heads up. I just found some places in the IEEE 128-bit floating point code
where it doesn't handle conversions to/from __ibm128. Nor does it generate the
same names for -mabi=ieeelongdouble. I will submit a revised patch when it is
ready.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King
46 matches
Mail list logo