similar to: [LLVMdev] ia64 target problems with ELF sections

Hello, Roman > llc: /opt/llvm/lib/Target/ELFTargetAsmInfo.cpp:133: const > llvm::Section* llvm::ELFTargetAsmInfo::MergeableStringSection(const > llvm::GlobalVariable*) const: Assertion `getCStringSection() && > "Should have string section prefix"' failed. > > Is it a bug in the ia64 backend? In general - yes. Please file a PR. I should introduce a fallback

Inspired by the dicussion of removing IA64, I just tried running llc over test/CodeGen/Generic targeting all the legal values of -march and counting the number of crashes and aborts, as an attempt to roughly measure the maturity/bitrottedness of the backends. I went through and fixed some easy legalization issues; the following is the remaining issues: x86-64: 3. I'm not entirely sure

Hi, Using llvm-stress, I got a crash after Post-RA pseudo expansion, with machine verifier. A 128 bit register %vreg233:subreg_l32<def,read-undef> = LLCRMux %vreg119; GR128Bit:%vreg233 GRX32Bit:%vreg119 gets spilled: %vreg265:subreg_l32<def,read-undef> = LLCRMux %vreg119; GR128Bit:%vreg265 GRX32Bit:%vreg119 ST128 %vreg265, <fi#10>, 0, %noreg;

I've attached the module->dump() that our code is producing. Unfortunately this is the smallest test case I have available. This is before any optimization passes are applied. There are two separate modules in existence at the time, and there are no guarantees about the order the surrounding code calls those functions, so there may be some interaction between them? There shouldn't

Adam, I just fixed this issue a few days ago. A version from the trunk should work for you. Cheers, Nadav -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ihusar Sent: Tuesday, February 15, 2011 15:52 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] How to use ConstantFoldConstantExpression? I forgot to mention, that I use

I forgot to mention, that I use LLVM release 2.8, I did not try it with the latest revision, but I expect that I am rather doing something wrong than using non-implemented functions. On Tue, 15 Feb 2011 14:09:57 +0100, ihusar <ihusar at fit.vutbr.cz> wrote: > Hello, > > i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, > however

Hello, i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? My code looks something like this: //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 const char* const TARGET_DATA_LAYOUT =

The scoreboard hazard detector that I've added for the PPC 440 is not detecting hazards as it should (which certainly could be my fault somehow, but...). For example, it will produce a schedule that looks like... SU(28): 0x127969b0: f64,ch = LFD 0x12793aa0, 0x1277b4f0, 0x127965b0<Mem:LD8[%scevgep100](tbaa=!"double")> [ORD=41] [ID=28] SU(46): 0x12796ab0: f64 = FADD 0x127969b0,

Two failing tests on x86-32 linux: FAIL: test/FrontendC/2008-08-07-AlignPadding1.c Failed with exit(1) at line 1 while running: /usr/local/bin/llvm-gcc -emit-llvm -w test/FrontendC/2008-08-07-AlignPadding1.c -m64 -S -o - -emit-llvm -O0 | grep

Hello, Pekka > 12) getSectionForFunction(*f) to f->getSection() This is not a correct substitution. Function::getSection() returns section set on function explicitely, getSectionForFunction() calculated desired section name, where function should be emitted into (for example, unique function name for linkonce stuff). getSectionForFunction() was replaced with universal

> So %passthrough can *only* be undef or zeroinitializer? No, it can be any value including undef and zeroinitializer. We considered, while designing, zero and merge semantics and decided that merge semantics is better because it covers zero semantics if you use zeroinitializer in the %paththru. - Elena -----Original Message----- From: dag at cray.com [mailto:dag at cray.com] Sent:

On 8/24/11 1:51 PM, Eli Friedman wrote: > On Wed, Aug 24, 2011 at 11:41 AM, John Criswell<criswell at illinois.edu> wrote: >> Dear All, >> >> I currently have one of my transforms creating the following store >> instruction: >> >> store [65536 x i8] zeroinitializer, [65536 x i8]* %buf.i, align 16 >> >> ... which causes the SelectionDAG code

Hi Micah, all, On Dec 13, 2011, at 8:49 AM, Villmow, Micah wrote: If you look at the test cases, you can infer what needs to be done. Basically since this is targeted for OpenCL, we annotate OpenCL kernels slightly different than normal functions and that is what causes the code to be generated. That being said, on my list of things to do is fix this so that any function will be generated

Hi, opt -O1 converts the attached test.ll to test_opt.ll. " opt --version LLVM (http://llvm.org/): LLVM version 3.8.0 DEBUG build with assertions. Built Jun 23 2016 (18:32:09). Default target: i686-pc-linux-gnu Host CPU: k8-sse3 " test.ll: " ; ModuleID = 'test.bc' @__mla__system.1 = global i32 0 @0 = internal global [12 x i8] zeroinitializer @1 = internal global

In a debug build you should get a stack trace by default, which would be helpful here. I can try to repro later today, but I'm not surprised there are issues because most people I know stick with 32-bit builds even on 64-bit Windows. On Mon, Apr 29, 2013 at 4:27 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > > > I check-out the latest version of

> The problem with this is that __register_frame function (in libgcc_s.so), > registering .eh_frame with an exception handler, only takes the pointer to > .eh_frame, and not the size of data, and should be able to detect the end of > data by scanning it and hitting zero DWORD (size). There is no trailing > zero, and it runs into the next section and tries to interpret it as an >

On 04/30/2013 11:53, Rafael Espíndola wrote: > Are you trying MCJIT?:-) No. > > I first tried to compensate for that in MCJIT by adding those 4 bytes. > That works for Linux, but not for OS X where __register_frame takes a > single FDE at a time. I have an incomplete wip patch if you are > interested. On BSD __register_frame also takes a single argument and therefore needs

On 26 July 2013 08:39, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 25 July 2013 17:24, Rui Ueyama <ruiu at google.com> wrote: >> Then how about enable these flags for -O2? I want to hear from other people >> cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF >> section if there's other mean already available to

On 25 July 2013 17:24, Rui Ueyama <ruiu at google.com> wrote: > Then how about enable these flags for -O2? I want to hear from other people > cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF > section if there's other mean already available to achieve the same thing. I would probably support doing that first. A small annoyance is that the linker

On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. > > From