[llvm-commits] [llvm] r115255 - /llvm/trunk/docs/LangRef.html

[Nick Lewycky]

Dale Johannesen wrote:
>
> On Sep 30, 2010, at 6:02 PMPDT, Nick Lewycky wrote:
>
>> Dale Johannesen wrote:
>>>
>>
>> Hold on, the rule is that you can have an undef of any type, and I think you can have a null/zeroinitialized of any type too.
>
> There was indeed some code assuming you could make a zero of any type.  I changed it.
>
> The whole point of this type is that the optimizers are not allowed to manipulate it.  They should not be creating undefs or constants of this type either.

Sure, but tools like bugpoint will try to eliminate instructions by 
replacing their uses with undef. How painful would it be to make 'x86mmx 
undef' legal?

>> If you really can't permit this -- I hate to say it after you've done all this work -- but how bad would it be to make MMX work like the half-width float support, where there are only intrinsics to do conversions to and from, while operations have to be done on a proper LLVM type? It sounds like that model may be a better fit.
>
> In general operations do have to be done on a proper LLVM type.   What are you seeing that you think should change?
>
> I started out with conversion intrinsics instead of bitcasts, but Chris preferred to allow bitcasts (which is certainly simpler to do).  This entire model is basically Chris's idea.

Okay -- I have to admit that I don't understand the whole EMMS issue 
that makes MMX hard to begin with, so I can't intelligently propose a 
solution. Ignoring the backend requirements, the two designs that make 
sense to me from an IR point of view are either having 
'llvm.convert.{to,from}.packed{byte,word,dword,qword} (i64)' intrinsics, 
or else having llvm.load/store.packed... which produces an i64 that can 
be bitcast to the right type for computation.

I initially thought the new type was going to be in the backend only 
which is why I didn't ask for an addition to the langref back then, but 
if it's going to be in the IR, I just want it to fit in with the rest of 
the design. Even metadata permits undef and null, for example.

Nick

>>> +
>>> +<h5>Syntax:</h5>
>>> +<pre>
>>> +  void
>>
>> "void" ->  "x86mmx" :)
>>
>> Nick
>>
>>> +</pre>
>>> +
>>> +</div>
>>> +
>>> +<!-- _______________________________________________________________________ -->
>>>   <div class="doc_subsubsection">   <a name="t_void">Void Type</a>   </div>
>>>
>>>   <div class="doc_text">
>>> @@ -2050,6 +2067,7 @@
>>>      they match the long double format on your target.  All hexadecimal formats
>>>      are big-endian (sign bit at the left).</p>
>>>
>>> +<p>There are no constants of type x86mmx.</p>
>>>   </div>
>>>
>>>   <!-- ======================================================================= -->
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>
>
>