Open andrjohns opened 7 months ago
I think this is intentional behavior. We currently only support SoA in user defined functions if we can inline them (see #1237), and it is unclear whether or not the user providing external C++ would desire SoA or AoS inputs.
The later is perhaps something we could fix with annotations once we implement them
Ah got it, thanks!
it is unclear whether or not the user providing external C++ would desire SoA or AoS inputs.
Actually, I might reopen sorry. I think that concern is only relevant if the user has passed the --O1
flag. If they're using -fsoa
then it should be assumed that they specifically want SoA.
Would a compromise be to allow this with the -fsoa
flag but output a warning/message?
At the moment, the optimizer has no way of knowing whether the reason it is doing the memory pattern optimizations is because it is from -fsoa
or --O1
-- both those flags just set the same boolean internally. I'd be a bit hesitant to make them have different behavior
Ahhh that makes sense, fair enough
It looks like
stanc
ignores the-fsoa
flag if any undefined functions are used in the likelihood. Given the following model:I get the following generated c++:
If I remove the
undefined_fun()
call from the likelihood:I instead get:
Both models were called with
./mac-stanc ./soa_test.stan -fsoa --allow-undefined
using the Oct 23 nightly (the latest release)