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

Refactor implicit conversions #1

Closed
vosen opened this issue Sep 19, 2020 · 0 comments
Closed

Refactor implicit conversions #1

vosen opened this issue Sep 19, 2020 · 0 comments
Assignees

Comments

@vosen
Copy link
Owner

vosen commented Sep 19, 2020

Implicit conversions are a pain. With ArgumentSemantics, we have all the necessary data during emission of implicit conversions. The problem is that implicit conversions are rife with special cases.
At top level we will start with tuple (expected type, actual type, semantics, conversion_fn) and convert it to (expected type', actual type' conversion_fn'). conversion_fn is normal register conversion rules or relaxed src/dst if it's physical ld/st.
With, the logic being:

  • If semantics is "address", then trigger super-special address conversion logic
  • If semantics is "physical pointer, then expected type' is b64 and conversion_fn' is to convert to physical pointer from u64/b64/s64
  • If semantics is "register pointer", then conversion_fn' is to force-convert

Open questions:

  • widening/narrowing conversions (force-convert, relaxed-convert) applying to vectors with different vector component width
  • implicit conversions scalar type <-> vector type
  • different semantics between .params variable from argument and .params variable from kernel body statement
@vosen vosen self-assigned this Sep 19, 2020
@vosen vosen closed this as completed Nov 1, 2020
vosen added a commit that referenced this issue Apr 27, 2024
vosen added a commit that referenced this issue Aug 6, 2024
vosen added a commit that referenced this issue Aug 6, 2024
vosen added a commit that referenced this issue Aug 22, 2024
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

No branches or pull requests

1 participant