[llvm-commits] [llvm] r120574 - /llvm/trunk/lib/Target/X86/X86ISelLowering.cpp

[Dan Gohman]

On Dec 1, 2010, at 12:29 PM, Duncan Sands wrote:

>>> I don't think it makes any sense to assert that the target supports SSE3 here.
>>> The user (i.e. whoever generated a call to the intrinsic in the first place) is
>>> essentially asking for a particular instruction to be placed in the assembler.
>>> If that instruction won't execute on the target machine, that's their problem
>>> not ours.  Two buildbots with processors that don't support SSE3 were barfing
>>> on the apm.ll test in CodeGen/X86 because of this assertion.
>> 
>> Or we could just make sure the testcase uses sse3 for codegen?
> 
> That was the other possibility, but since I don't see the point in asserting

The rest of codegen doesn't support subtarget-specific intrinsics when
the target doesn't claim to support them, so it's inconsistent to do
so here.

It's a complicated issue. There are two main situations where it makes sense for
an IR producer to use these intrinsics. Either it knows that the actual target
hardware will support them, in which case it ought to be telling Codegen that,
or it doesn't, and it's presumably using runtime checks to test whether the
actual hardware in use supports them.

LLVM doesn't really support the runtime checks approach, because there's
nothing that prevents it from moving an intrinsic call ahead of the dynamic
checking.

> I went for this one instead (nothing else in the code generators blows up if
> you do this).  Do you think an assertion is better?  Philosophically an
> assertion is wrong since it should only be used in impossible situations which
> this is clearly not!


Instead of an assertion, it should use report_fatal_error.

Dan