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

[Dale Johannesen]

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.

> 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.

>> +
>> +<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
>> 
>