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
Cross-posting from harvard-acc/smaug#102, as this is mainly an Aladdin bug, not a SMAUG bug. The reason is this: typically, we store the name of the array being dereferenced in the array_label field of ExecNode. This works fine for very simple code, but it breaks down very easily. In this particular case, we have a hostLoad operation, which is not treated like a normal load or store:
For hostLoad and hostStore operations, we don't fill in an array name in the ExecNode in the first place: link. Unlike normal loads and stores from a scratchpad or cache, these are bulk transfer operations which have two addresses (source and dest), and it's not obvious which one the array_label would refer to.
Even if we had filled in one of these, it wouldn't be guaranteed to work. The compiler can insert additional operations like bitcasts or phis which effectively cause the array to be renamed in the trace to something like add.ptr13 rather than orig_function_param_name. Again, this is a fundamental problem of Aladdin's reliance on variable names, which has caused no end of issues like this and resulted in numerous band-aid solutions that only partially solve the problem (such as the "forward" parameters in function calls).
The only reliable way to address this is to use the address itself as the lookup key and find the array whose address range covers that key.
The text was updated successfully, but these errors were encountered:
Cross-posting from harvard-acc/smaug#102, as this is mainly an Aladdin bug, not a SMAUG bug. The reason is this: typically, we store the name of the array being dereferenced in the
array_label
field ofExecNode
. This works fine for very simple code, but it breaks down very easily. In this particular case, we have ahostLoad
operation, which is not treated like a normal load or store:hostLoad
andhostStore
operations, we don't fill in an array name in theExecNode
in the first place: link. Unlike normal loads and stores from a scratchpad or cache, these are bulk transfer operations which have two addresses (source and dest), and it's not obvious which one thearray_label
would refer to.add.ptr13
rather thanorig_function_param_name
. Again, this is a fundamental problem of Aladdin's reliance on variable names, which has caused no end of issues like this and resulted in numerous band-aid solutions that only partially solve the problem (such as the "forward" parameters in function calls).The only reliable way to address this is to use the address itself as the lookup key and find the array whose address range covers that key.
The text was updated successfully, but these errors were encountered: