Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add IntegerType.isPointer() #572

Closed
wants to merge 1 commit into from
Closed

Add IntegerType.isPointer() #572

wants to merge 1 commit into from

Conversation

xeren
Copy link
Collaborator

@xeren xeren commented Nov 15, 2023

This PR adds means to differentiate the types ptr and bv64.
This is a lightweight alternative to #550. It does not forbid multiplications or bit operations on pointers, and does not require pointer expressions as addresses of memory events. Assignments, however, raise an exception on type mismatch.

@ThomasHaas
Copy link
Collaborator

ThomasHaas commented Nov 17, 2023

After thinking about this for some time, I don't think we should start to flag integers as being pointer/no pointers.
One reason for a dedicated pointer type is the idea of address spaces, which might be necessary in the near future when dealing with OpenCL or CUDA, or maybe even just ASL.
I can also imagine that a distinction between physical and virtual pointers could be useful.
All these things should not be implemented on top of integers with extra attributes I believe.

I think one of the ugly parts about supporting pointer types is the GEP expression.
Maybe adding pointer types is not so bad if we avoid GEP for now and instead allow pointer-typed left operands in all binary expressions. So ptr + 8 would still be valid and it would be of pointer type (the type of the binary expressions matches the left operand).
Alternatively, we can have something like GEP possibly without the type parameter (i.e., we always use byte offsets), but still use the standard makeAdd/makeSub/etc. factory methods which could automagically generate the GEP if a pointer was provided instead of an int.

Either way, I think we need proper pointer types (eventually). To eaze in the implementation, I think it would be fine to still allow arbitrary integer expressions as addresses, so that the backend doesn't need to change immediately. We can then step-by-step introduce pointer types into use, temporarily allowing for both pointers and integers serving as addresses.

EDIT:
There are discussion on removing GEP from LLVM and instead use a ptradd instruction (which amounts to GEP with i8):
https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699

@hernanponcedeleon
Copy link
Owner

As discussed.

@hernanponcedeleon hernanponcedeleon deleted the pointer-type0 branch February 18, 2024 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants