Graham Stott graham.st...@imgtec.com writes:
+(define_constraint YC
+ @internal
+ A constant vector with each element is a unsigned bitimm-bit integer with
only one bit set
Maybe:
A replicated vector constant in which the replicated value has a single
bit set
Likewise YZ and clear
Hi Richard,
Attached is an updated patch for feedback so MSA support to MIPS backend can
be added when open again for next stage1.
It is unfinished in that some comments from your review of the initial patch
have yet to be addressed.
The diff is against svn 207500
Graham
Hi Richard,
I'd like to get some more of your thoughts on the ABI implications of MSA.
Generally, any thoughts you have (or anyone else) on the current state of MIPS
ABIs would be welcome. As an example I'm curious whether you see variations of
O32 as being new ABIs or extensions of O32, it
On Tue, 21 Jan 2014, Matthew Fortune wrote:
The MSA patch as submitted is another variation of O32 ABI which could
be described as O32+FP64+MSA(+nan2008) and would be link incompatible
with both O32 and O32+FP64(+/-nan2008). The same of course applies to
N32/N64 being link incompatible
Hi Matthew,
Just wanted to add a couple of MIPS-specific things on top of what
Joseph said:
Matthew Fortune matthew.fort...@imgtec.com writes:
The MSA patch as submitted is another variation of O32 ABI which could
be described as O32+FP64+MSA(+nan2008) and would be link incompatible
with both
On Tue, 21 Jan 2014, Richard Sandiford wrote:
And as you imply, o32+fp64 is already an established ABI so I think we
have to support the current form alongside any new one. I agree with
Joseph that it'd be better to realign the stack dynamically instead.
This is what x86 does, so it's well
Just wanted to add a couple of MIPS-specific things on top of what Joseph
said:
Matthew Fortune matthew.fort...@imgtec.com writes:
The MSA patch as submitted is another variation of O32 ABI which could
be described as O32+FP64+MSA(+nan2008) and would be link incompatible
with both O32
And as you imply, o32+fp64 is already an established ABI so I think we
have to support the current form alongside any new one. I agree with
Joseph that it'd be better to realign the stack dynamically instead.
This is what x86 does, so it's well tested within gcc.
With glibc, o32+fp64
Hi Joseph,
Thanks for the comments I will address these issues and send an updated patch.
Graham
This patch inserts a #if 0 around existing code, which looks suspicious,
and appears to be missing documentation in invoke.texi for the new
command-line options, and extend.texi for the new built-in functions.
--
Joseph S. Myers
jos...@codesourcery.com
10 matches
Mail list logo
