[llvm-dev] Proposing a small change to the SelectionDAG class to support recover from LLVM IR

[Anton Korobeynikov via llvm-dev]

Alex,

>      I personally prefer keeping to my current implementation and ask the LLVM community
> to accept my changes (the number of changes is around 150 changes - the number is not
> actually a big problem) in SelectionDAGBuilder, DAGCombiner and SelectionDAG classes.
This is not how the review process works, you cannot just throw out
the comments and the # of LOCs does not matter. Your changes affect
all the targets and impose both memory- and compile-time increase (as
you need to track the values in this map), however, only a single out
of the tree target would benefit from it. It seems that you could
solve this particular problem in other ways as Craig suggested – there
are multiple ways how you could capture the necessary information
without pessimizing other targets. Roman's concerns were not answered
as well – you cannot rely that IR comes from a single source (e.g.
generated by clang).

Also I do not see why you can't solve this problem on SDAG level – it
seems that everything is much more simply there and you'd just need to
carefully pattern match the operands of your inline asm. After all,
many targets have complex addressing models allowing strides, offsets,
etc. and it seems here the situation is pretty much the same.

Thanks.
-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University