[llvm-dev] Clang for the PlayStation 2

[Dan Ravensloft via llvm-dev]

On Thu, 6 Sep 2018, 16:35 Daniel Sanders, <daniel_l_sanders at apple.com>
wrote:

>
>
> On 6 Sep 2018, at 08:00, Dan Ravensloft via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On Mon, 3 Sep 2018 at 13:31, Tim Northover <t.p.northover at gmail.com>
> wrote:
>
>> So the next step is to debug where Mips is producing those TruncIntFP
>> nodes. There'll be some constraint it's not checking or an unexpected
>> node type, probably related to -msingle-float. I'm afraid I'm not sure
>> what yet.
>
>
> FWIW, I'm not sure how well tested -msingle-float was on MIPS. I don't
> think we had any bots testing it.
>

Well, now we have hardware, if all of one machine, where it's worth
testing. I'm happy to try it myself if needed, though rigging it up to
happen automatically would be difficult.

> I'm reasonably sure the function producing that node
> is lowerFP_TO_SINT_STORE in lib/Target/Mips/MipsISelLowering.cpp.
>
> The node before that function executes has an fp_to_sint node which seems
> to want to convert an i64 to an f32 which seems...rather odd to me,
> honestly. The PS2, for what it's worth, only has an i32 -> f32 instruction,
> so I think there's an impedance mismatch somewhere.
>
>
> Did you mean those types to be the other way around? fp_to_sint is
> supposed to take a floating point type and produce an integer type so if
> you're seeing them backwards like this then that would definitely be a bug.
>

Yes, my mistake; I got confused by the direction of the arrows on the
graph, they're pointing to their parents, but I thought they were pointing
to their children.


> If you're referring to the size mismatch though, that's ok within the IR
> and DAG nodes. There's no relationship between the size of the input and
> output.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180906/6e064ffc/attachment.html>