search for: westdac

I'm not sure if this will do everything that you want, but it controls at least some of these expansions at the Clang level: tools/clang/lib/Basic/Targets.cpp On Tue, May 14, 2013 at 3:46 PM, Dan <westdac at gmail.com> wrote: > > I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile > for a target that I am developing. > > There is an example: AtomicOps, that uses calls to: > > __sync_fetch_and_add > __sync_val_compare_and_swap > __sync_lock_test_...

I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile for a target that I am developing. There is an example: AtomicOps, that uses calls to: __sync_fetch_and_add __sync_val_compare_and_swap __sync_lock_test_and_set These get converted into llvm IR operations like: atomicrmw cmpxchg Is there any way to keep these as function calls, as they are easier to map to the

I've inherited some target code, but there is no SELECT lowering in my target. But somewhere/somehow SELECT is being transformed into a predicated move. I've traced SELECT everywhere in Codegen/SelectionDAG. Any ideas on tracking this down to the point in Codegen lowering/dag-conversion to a predicated series? Again, I do not have a lowering rule in my target for SELECT. If I do a IR

I made the switch to llvm3.3, and encountered a flt_rounds I'm using a soft float architecture and hopefully people have some ideas on how to help: I received: i32 = flt_rounds "Do not know how to promote this operator!" I currently do not have any custom setting for the FLT_ROUNDS_ I'd like to just replace the FLT_ROUNDS_ with a "1" value. Any thoughts on how

This is more of a follow-up on an earlier question. If MUL MVT::i32 is getting promoted (to MVT::i64), is there any way to distinguish the Node later as it goes through lowering? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/28d7eba0/attachment.html>

I posted a similar issue, but this relates to how to keep a function call from being lowered to an ISD:FABS. In this case, I don't want FABS (floating point absolute) to be converted into an operation). In this case, what happens is that clang generates the code for floating point absolute (fabs) as a subroutine call: %5 = load douuble %x, align 8 %call = call double @fabs(double %5)

For a LLVM code target, I am developing a software-supported floating-point engine. I've come into a few issues in which the DAG conversion is Can anyone help with: I have some C code test like: float x; printf("%f", x); which clang coverts to: %0 = load float* @x, align 4 %conv = fpext float %0 to double The issue is for simple Float to Double extension, the DAGCombiner.cpp

Since updating to LLVM 3.3, the system is generating attributes such as: attributes #0 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false"

I am working on an experimental target and trying to make sure that the load offset field is used to the best way. There appears to be some control over the architecture's offset range and whether the offset is too large and needs to be lowered/converted into a separate sequence of operations in DAGSelection? Can someone point me to what might be the case? For example, the difference between

Thanks Tom. I really appreciate your insight. I'm able to use the customize to get the 64-bit to go to a subroutine and for the 32-bit, I am generate XXXISD::MUL32. I'm not sure then what you mean about "overriding" the ReplaceNodeResults. For ReplaceNodeResults, I'm doing: SDValue Res = LowerOperation(SDValue(N, 0), DAG); for (unsigned I = 0, E =

Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this

I'll try to run through the scenario: 64-bit register type target (all registers have 64 bits). all 32-bits are getting promoted to 64-bit integers Problem: MUL on i32 is getting promoted to MUL on i64 MUL on i64 is getting expanded to a library call in compiler-rt the problem is that MUL32 gets promoted and then converted into a subroutine call because it is now type i64, even though