Cross-posting from https://github.com/harvard-acc/smaug/issues/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.
Cross-posting from https://github.com/harvard-acc/smaug/issues/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_labelfield ofExecNode. This works fine for very simple code, but it breaks down very easily. In this particular case, we have ahostLoadoperation, which is not treated like a normal load or store:hostLoadandhostStoreoperations, we don't fill in an array name in theExecNodein 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_labelwould refer to.add.ptr13rather 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.