You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
expected type'
is b64 andconversion_fn'
is to convert to physical pointer from u64/b64/s64conversion_fn'
is to force-convertOpen questions:
The text was updated successfully, but these errors were encountered: