search for: libcal

On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: > 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any ideas about what is going wrong here? No idea why this stuff was there... Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92512) +++ TEST.libcalls.Makefile (working copy) @@ -21,12 +21,11 @@ @cat $< $(PROGRAMS_TO_TEST:%=Output/%.$(TEST).report.txt): \ -Output/%.$(TEST).report.txt: Output/%.linke...

On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: > looks like some lines got moved, fixed on mainline, thanks. Not really fixed :-) Please commit this: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92749) +++ TEST.libcalls.Makefile (working copy) @@ -23,10 +23,10 @@ $(PROGRAMS_TO_TEST:%=Output/%.$(TEST).report.txt): \ Output/%.$(TEST).report.txt: Output/%.linked.rbc $(LOPT) \...

This is what I get while trying to run 'make TEST=libcalls' in the top dir of test-suite: make[1]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource' make[2]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource/UnitTests' make[3]: Entering directory `/home/gregory/thesis/llvm/project...

Hi, Probably I did not mention my question correctly. I need to emit declarations of the libcalls (that are made in the current module) at the beginning of the assembly file. The class "Module" does not maintain any list of the libcalls made during the program. Although, it maintains lists of all the global variables and functions in the current module. Traversing each instruction...

...syan wrote: >> 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any >> ideas about what is going wrong here? > > No idea why this stuff was there... looks like some lines got moved, fixed on mainline, thanks. -Chris > > Index: TEST.libcalls.Makefile > =================================================================== > --- TEST.libcalls.Makefile (revision 92512) > +++ TEST.libcalls.Makefile (working copy) > @@ -21,12 +21,11 @@ > @cat $< > > $(PROGRAMS_TO_TEST:%=Output/%.$(TEST).report.txt): \ > -Output/...

Right now, the atomics implementation in clang is a bit of a mess. It has three basically completely distinct code-paths: There's the legacy __sync_* builtins, which clang lowers directly to atomic IR instructions. Then, the llvm atomic IR instructions themselves can sometimes emit libcalls to __sync_* library functions (which are basically undocumented, and users are often responsible for implementing themselves if they need it). There's the new __atomic_* builtins, which clang will, depending on size and alignment and target, lower either to a libcall to a "standardized-b...

Doh, thanks, done. -Chris On Jan 5, 2010, at 11:27 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: >> looks like some lines got moved, fixed on mainline, thanks. > > Not really fixed :-) Please commit this: > > Index: TEST.libcalls.Makefile > =================================================================== > --- TEST.libcalls.Makefile (revision 92749) > +++ TEST.libcalls.Makefile (working copy) > @@ -23,10 +23,10 @@ > $(PROGRAMS_TO_TEST:%=Output/%.$(TEST).report.txt): \ > Output/%.$(TEST).report.txt: O...

...ing a mips target that only supports single float point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. What if I want a libcall instead? What should I do? The libcall FROUND_F64_F32 is there, but it seems that it cannot be reached without hacking. What should I do to support this? Am I missing something? Thanks, -- Bruno Cardoso Lopes http://www.brunocardoso.cc "When faced with untenable alternatives, you should c...

On Tue, Jan 05, 2010 at 11:42:10AM -0800, Chris Lattner wrote: > Doh, thanks, done. LOL. Next patch should be titled 'really really really fix this' :-) Please apply the last part of the diff, too: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92757) +++ TEST.libcalls.Makefile (working copy) @@ -27,7 +27,6 @@ @echo "---------------------------------------------------------------" >> $@ @echo ">&g...

...appropriate place in your assembly file. Would that work? -bw On Jan 28, 2009, at 12:23 AM, <Sachin.Punyani at microchip.com> <Sachin.Punyani at microchip.com > wrote: > Hi, > > Probably I did not mention my question correctly. > > I need to emit declarations of the libcalls (that are made in the > current module) at the beginning of the assembly file. The class > “Module” does not maintain any list of the libcalls made during the > program. Although, it maintains lists of all the global variables > and functions in the current module. > > T...

...plementation in clang is a bit of a mess. It > has three basically completely distinct code-paths: > > 1. There's the legacy __sync_* builtins, which clang lowers directly > to atomic IR instructions. Then, the llvm atomic IR instructions > themselves can sometimes emit libcalls to __sync_* library > functions (which are basically undocumented, and users are often > responsible for implementing themselves if they need it). > 2. There's the new __atomic_* builtins, which clang will, depending > on size and alignment and target, lower either to...

...arations (use the > "Function::isDeclaration()" method), and then placing them in the > appropriate place in your assembly file. > > Would that work? Hi Bill, Function definitions and declarations that are parsed by clang make part of the FunctionList in Module. However the libcalls that are created during the lowering do not make part of this list. For example PIC16 does not support shift operation of 16 bits. For this LLVM generates the libcall. For creating such a call it uses ExternalSymbol and therefore it is not available in the FunctionList. I need to emit declarati...

Sanjiv Gupta wrote: > Sanjiv Gupta wrote: > >> Duncan Sands wrote: >> >> >>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >>> with float (32 bits). So it's not just a matter of changing the libcall >>> return type. >>> >>> >>> >> Yes, we are dealing with 32-bits only. But why the cmp libcalls have to >> return a 32-bit value. >> e.g. Our libcall for comparing two floats is >> >> char _eq_f32 (float a, float b);...

Hi All, I need to print some extra information about libcall names in assembly. Libcall names are managed as ExternalSymbols in LLVM. How do I access these ExternalSymbols from Asmprinter? AsmPrinter uses class Module that lists all the global variables (including extern variables) and functions (include extern functions). But it does not list an...

...O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one example so that I can trace the LLVM source code on my own? Thanks. Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://li...

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::S...

...eviews.llvm.org/D54583. However, when building compiler-rt's lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is not legal on line 24. There should be no bitcast(buildpair) anywhere in the generation, as it should all be lowered. However, this is not the case when lowering to a libcall it seems. The relevant debug output, is here: Creating new node: t118: i64 = build_pair t117,t116, /home/chmeee/freebsd/contrib/compiler-rt/lib/builtins/divdc3.c:24:22 Creating new node: t119: f64 = bitcast t118, /home/chmeee/freebsd/contrib/compiler-rt/lib/builtins/divdc3.c:24:22 Created libcal...

...t; only supports single > float point operations. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. > What if I want a libcall instead? What should I do? The libcall FROUND_F64_F32 > is there, but it seems that it cannot be reached without hacking. What > should I do > to support this? Am I missing something? with the new LegalizeTypes infrastructure you could add a method to DAGTypeLegalizer::SoftenFloatOperand...

Hi, I tried out the new soft-float support from the mainline. Overall, it looks very nice and pretty clean. It is now extremely easy to add the soft-float support for your target. Just do not call addRegisterClass() for your FP types and they will be expanded into libcalls. But there are several minor things that would be still nice to have: a) It is not possible to express that: - f32 and f64 are both illegal and therefore are mapped to integers - but only f64 is emulated on the target and there are no f32 arithmetic libcalls available (which is the case o...

...> sequence which is better than the default expansion. I don't think so. Single-instruction support for i64 exists in instructions such as storing and loading from memory and multiplication. For other instructions, such as converting to and from other data types, division, remainder etc., libcalls exist. Other instructions can and will be simulated by a sequence of i32 instructions. I thought that a target supports a datatype when it can produce the correct semantics for all necessary operations on that datatype, regardless of whether single instructions exist for all operations on tha...