On 02/04/2016 12:46 AM, Richard Biener wrote:
On February 3, 2016 8:11:01 AM GMT+01:00, Richard Henderson <r...@redhat.com>
wrote:
On 02/03/2016 06:05 PM, Richard Biener wrote:
I wasn't aware that STRIP_NOPS strips ADDR_SPACE_CONVERT_EXPR.
Isn't this maybe failing to use that (unable to look at the
attachment from my phone).
The test case does fail to use ADDR_SPACE_CONVERT_EXPR.
Perhaps it's because of the intermediate cast to uintptr_t?
Ah. Isn't to/from int conversion also address-space specific?
No, we just copy the bits there.
I wonder if it makes sense to have ADDR_SPACE_CONVERT if there is the
loophole of going through an integer type...
Dunno.
That is, if the address spaces are not subsets, how can going through an int
make sense? Isn't the testcase somehow invalid then?
Well, that depends. For x86, they really are subsets, but the compiler does
not know the relationship between them, so it cannot perform the conversion itself.
The test case is using implementation-defined conversions between pointers and
integers (GCC defines the conversion to be bitwise). So I don't think the test
case is in any way invalid.
The user-friendly way to do this would probably be some sort of pragma that
allows user-defined address spaces, and user-defined conversion between them.
But that's certainly not going to happen in the near-term.
[ Irritatingly, there's a new Haswell instruction that would allow the compiler
user-space access to the fs/gs_base registers, and then the compiler really
would know the relationship.
However, the new instruction needs to be enabled by the OS, and not one has
done so yet. Then there's that further complication of all those non-Haswell
cpus still running around. So in practice we'd still want to be using the
user-defined spaces. ]
As for a patch I'd repeatedly pondered on not stripping int <-> pointer
conversions at all, similar to what STRIP_SIGN_NOPS does. Don't remember
actually trying this or the fallout though.
I'll run that through a test cycle and see what happens.
r~
