Displaying 4 results from an estimated 4 matches for "017b7e78".
2008 Sep 10
2
[LLVMdev] Custom Lowering and fneg
...%x ; <float>
[#uses=1]
store float %neg, float addrspace(11)* %result
ret void
}
However, when I attempt to run it through my backend which can handle
binary math ops correctly I keep asserting on the following item.
Cannot yet select: 017B8010: i32 = fneg 017B7E78
What I cannot figure out is why it is attempting to pattern match on an
i32 when there are no i32's in my test program.
I've tried a custom lowering function that lowers it to dst = sub 0,
src0 and forcing it to f32, but it complains that result and the op
value types are incorrect....
2008 Sep 10
0
[LLVMdev] Custom Lowering and fneg
...[#uses=1]
> store float %neg, float addrspace(11)* %result
> ret void
> }
>
> However, when I attempt to run it through my backend which can handle binary
> math ops correctly I keep asserting on the following item.
>
> Cannot yet select: 017B8010: i32 = fneg 017B7E78
That seems strange... you definitely shouldn't be seeing an fneg with
an i32 result. What sorts of changes have you made to the SPARC
backend? Have you tried looking at the output of "llc
-view-dag-combine1-dags" and "llc -view-legalize-dags" to see where
exactly this nod...
2008 Sep 10
3
[LLVMdev] Custom Lowering and fneg
...[#uses=1]
> store float %neg, float addrspace(11)* %result
> ret void
> }
>
> However, when I attempt to run it through my backend which can handle
binary
> math ops correctly I keep asserting on the following item.
>
> Cannot yet select: 017B8010: i32 = fneg 017B7E78
That seems strange... you definitely shouldn't be seeing an fneg with
an i32 result. What sorts of changes have you made to the SPARC
backend? Have you tried looking at the output of "llc
-view-dag-combine1-dags" and "llc -view-legalize-dags" to see where
exactly this nod...
2008 Sep 16
0
[LLVMdev] Custom Lowering and fneg
...[#uses=1]
> store float %neg, float addrspace(11)* %result
> ret void
> }
>
> However, when I attempt to run it through my backend which can handle
binary
> math ops correctly I keep asserting on the following item.
>
> Cannot yet select: 017B8010: i32 = fneg 017B7E78
That seems strange... you definitely shouldn't be seeing an fneg with
an i32 result. What sorts of changes have you made to the SPARC
backend? Have you tried looking at the output of "llc
-view-dag-combine1-dags" and "llc -view-legalize-dags" to see where
exactly this nod...