On Wed, Apr 4, 2012 at 3:26 PM, Richard Henderson <r...@redhat.com> wrote: > On 04/04/2012 04:45 AM, Richard Guenther wrote: >> I suppose you do not want to use builtins because for primitive types you >> end up with multiple statements for something "atomic"? > > The primary motivation is that builtins cannot return two values. > > Our current builtin returns one of the two values by reference, as > one would do from plain old C. Even though we drop the reference > when we convert from gimple to rtl, this is not good enough to clean > up the variable we forced to a stack slot.
If that is the only reason you can return two values by using a complex or vector type (that would be only an IL implementation detail as far as I can see). We use that trick to get sincos () "sane" in our IL as well. Are there other reasons to go with a new GIMPLE code? > I suggested a specialized GIMPLE_ATOMIC opcode instead of doing a > totally generalized GIMPLE_ASSIGN_N, returning N values. We already support multiple SSA defs btw, there is just no operand slot for it that is properly named or handled by the operand scanner. Thus, a new GIMPLE_ASSIGN sub-code class would do, too (of course nobody expects multiple DEFs here thus it would not be a very good idea to do that, IMHO). Richard. > > r~