Matthew Fortune writes:
> Mike Stump writes:
>> On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
>> >
>> > Speed of implementation. We're gradually replacing these with proper
>> > builtins, but that takes a lot more work.
>>
>> As an owner of a port with more builtins that yours, I can of
Hi Graham,
Thanks for the patch. I agree with what Richard and Joseph said. Also...
I think it'd be better to keep the p5600 bits separate and wait until
the main p5600 patch has gone in. It looks like it uses a different
naming scheme for the insn reservations.
Graham Stott writes:
> +(defi
On Wed, May 28, 2014 at 6:49 PM, Mike Stump wrote:
> On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
>>
>> Speed of implementation. We're gradually replacing these with proper
>> builtins, but that takes a lot more work.
>
> As an owner of a port with more builtins that yours, I can offer a
Mike Stump writes:
> On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
> >
> > Speed of implementation. We're gradually replacing these with proper
> > builtins, but that takes a lot more work.
>
> As an owner of a port with more builtins that yours, I can offer a
> technological solution to
On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
>
> Speed of implementation. We're gradually replacing these with proper
> builtins, but that takes a lot more work.
As an owner of a port with more builtins that yours, I can offer a
technological solution to reduce the cost of builtins to:
On 28/05/14 09:03, Matthew Fortune wrote:
>> You shouldn't need to declare __builtin_* functions anyway. And if a
>> function can be represented directly with GNU C vector extensions, it's
>> preferred to implement it that way inline in the header rather than having
>> built-in functions duplicati
On May 28, 2014, at 1:03 AM, Matthew Fortune wrote:
>> You shouldn't need to declare __builtin_* functions anyway. And if a
>> function can be represented directly with GNU C vector extensions, it's
>> preferred to implement it that way inline in the header rather than having
>> built-in funct
> You shouldn't need to declare __builtin_* functions anyway. And if a
> function can be represented directly with GNU C vector extensions, it's
> preferred to implement it that way inline in the header rather than having
> built-in functions duplicating existing GNU C functionality. (Look at
> w
> +(define_expand "one_cmpl2"
> + [(match_operand:IMSA 0 "register_operand")
> + (match_operand:IMSA 1 "register_operand")]
> + "ISA_HAS_MSA"
> +{
> + if (mode == V16QImode)
> +emit_insn (gen_msa_nori_b (operands[0], operands[1], const0_rtx));
> + else
> +{
> + rtx reg = gen_reg_
On Wed, 21 May 2014, Graham Stott wrote:
> msa.h is included, which will be installed when configured/built/installed.
> It provides prototypes, typedefs etc for the vector types used MSA its
> contents follow the MSA whitepaper.
Unless it's part of the defined interface that the user may not
10 matches
Mail list logo
