summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/X86/atomic-non-integer.ll
Commit message (Collapse)AuthorAgeFilesLines
* [X86][SSE2] Fix asm string for movq (Move Quadword) instruction.Ayman Musa2017-04-261-4/+4
| | | | | | | | Replace "mov{d|q}" with "movq". Differential Revision: https://reviews.llvm.org/D32220 llvm-svn: 301386
* CodeGen: check return types match when emitting tail call to builtin.Tim Northover2016-03-221-1/+1
| | | | | | | | | | | We were just completely ignoring the types when determining whether we could safely emit a libcall as a tail call. This is clearly wrong. Theoretically, we could dig deeper looking for incidental matches (much like the generic code in Analysis.cpp does), but it's probably not worth it for the few libcalls that exist. llvm-svn: 264084
* [IR] Add support for floating pointer atomic loads and storesPhilip Reames2015-12-161-0/+108
This patch allows atomic loads and stores of floating point to be specified in the IR and adds an adapter to allow them to be lowered via existing backend support for bitcast-to-equivalent-integer idiom. Previously, the only way to specify a atomic float operation was to bitcast the pointer to a i32, load the value as an i32, then bitcast to a float. At it's most basic, this patch simply moves this expansion step to the point we start lowering to the backend. This patch does not add canonicalization rules to convert the bitcast idioms to the appropriate atomic loads. I plan to do that in the future, but for now, let's simply add the support. I'd like to get instruction selection working through at least one backend (x86-64) without the bitcast conversion before canonicalizing into this form. Similarly, I haven't yet added the target hooks to opt out of the lowering step I added to AtomicExpand. I figured it would more sense to add those once at least one backend (x86) was ready to actually opt out. As you can see from the included tests, the generated code quality is not great. I plan on submitting some patches to fix this, but help from others along that line would be very welcome. I'm not super familiar with the backend and my ramp up time may be material. Differential Revision: http://reviews.llvm.org/D15471 llvm-svn: 255737
OpenPOWER on IntegriCloud