similar to: [LLVMdev] Introduction for new consumer of LLVM

Yes. We currently build LLVM 3.4.2 on our OpenVMS Itanium box with an older EDG/Intel C++03 compiler to create legacy cross-compilers to our OpenVMS x86 box (well, VirtualBox). We do have a few tweaks to the relocations to access static data always through the GOT (including CodeGen's static data). Our linker sees references to code (which might be in 64-bit space) and creates trampolines

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF > Bastien via llvm-dev > Sent: Thursday, June 13, 2019 12:25 PM > To: John Reagan > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Coding Standards: "prefer `int` for, regular > arithmetic, use `unsigned` only for bitmask and when you, intend to

On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de> wrote: vector.size() returns a size_t, which on 64-bit platforms can represent types values larger than those that can fit into an int64_t. So to turn your argument around, since it's theoretically possible to have a vector with more items than an int64_t can represent, isn't it already worth it to use

Hello Paul, Thanks for the reply. Yes, I am only looking for dwarf support at the moment and planning to support both PLI/COBOL decimal types. Also thanks for the suggestion, you are right as it is going to be rare cases, so it will be better to implement a separate subclass to avoid memory overhead for others. >> (Somebody is actively working on scaled binary operations, although they

As one of the OS' without current CMake support, I'm closely watching this discussion. We currently have LLVM 3.4.2 hosted on OpenVMS Itanium (as a host only, x86 target) using configure/make with little hassle. We plan to port CMake to OpenVMS, but that has been trickier than you'd think (others have tried, I haven't found anybody who has done it). Looks like I'll want to

We use .note descriptors with ELF on OpenVMS.  We have self-describing entries with tags and lengths.  The compiler encodes stuff for the linker such as compiler version, compilation date-time, module name, final severity of the compilation, etc.  The linker itself then adds/modifies the .note entries to insert linker version, link date/time, etc.  We also use .notes to record floating point

I had thought about "used", but not aware of the @llvm.used, et al. I wrote some test programs with __attribute__((used)) but that felt like something you'd put on function definitions to force code to be generated regardless. In the worst case, I'll do some metadata hack (I've ready had to do that for BLISS' GLOBAL BIND feature). Thanks for the response. I'll let

I think it's valuable to have precise / asynchronous unwind information without adding support for non-call exceptions. Profilers and debuggers need to be able to unwind the stack from arbitrary instruction boundaries, but they don't need to run exception handlers. We can still declare that outside the model. Speaking of which, barring bugs, we do support precise unwind info on Win64.

I'm defining an external function in the IR that has no uses at all. No calls, no address taken, nada. Such an unused declaration seems to be just dropped on the floor as not needed. Seems reasonable in most cases. However, one of my OpenVMS compilers (BLISS) has a language rule that expects such definitions to get into the ELF symbol table as a way to compel the linker to include certain

As part of our port of OpenVMS to x86-64, we are using LLVM with our own frontends on OpenVMS Itanium. We are writing a converter between our old backend's IR and the LLVM IR. We can cross-compile (hosted on OpenVMS Itanium) and link/execute on x86-64 CentOS. At present, we pass over 88% of our C test suite. Porting starts with being able to compile the code. Since we are stuck with a

As somebody who's currently hosting LLVM on a platform (OpenVMS Itanium) that has configure but not a working CMake (we're working to fix that but there are some tricky issues), I would appreciate if you didn't scrub the existence of configure from the source or the documentation. Perhaps keep pointers to the older pages and link to them from the downloads pages or something with an

I'm not sure if they are doing an x86 to IA64 cross compile, but in any event I'm going to guess they may need an ancient version to avoid any C++11 dependencies. In terms of IA64 compilers you have afaik 3 choices HP compiler, Open64 and Intel? (Does gcc still support it and how up-to-date or EOL is the Intel compiler IA64 support?) I really hope nobody decides not to move to a more

On Wed, May 18, 2016 at 01:10:50PM +0000, Daniel Sanders via llvm-dev wrote: > It's my understanding that llvm-mc is intended to be a testing tool > for LLVM developers rather than an assembler for end users. Users > should be assembling with clang. Not all LLVM users are clang users. For example, we're using LLVM to build OpenVMS cross-compilers to x86 for our porting effort.

When I worked on the HPE NonStop compilers for x86 (we used Open64, not LLVM), we adjusted our -O1 to make sure the source display didn't "bounce around" based on feedback from users. We disabled any optimization that would move things across statement boundaries. We also disabled/de-tuned dead store since our DWARF location list support was pretty basic and with the removed store,

That is basically what we do today to provide mixed sized pointers with our legacy frontends. They generate IR to our old code generator which has ADDR32 and ADDR64 datatypes. We use a 64-bit address data layout and then typecast the 32-bit forms to/from the underlying 64-bit addresses. I have been warned that such rampant typecasting might interfere with certain optimizations or TBAA data. We

Please review the properties of an address space which are configurable via the data layout.  For example, bitwidth is one of those parameters.  If that parameter space covers your needs, then you do not need LLVM side support. Philip On 7/30/19 2:59 PM, Amy Huang wrote: > Thanks for the info-- > It seems like the way to do this is for clang to use address spaces to > represent

Hello all, Pardon me if this has already been covered elsewhere, however I have not been able to find such documentation. Is there a consolidated set of documentation that clearly explains what's necessary to port LLVM to other OSes & how to add support for building executables (& libraries) for those OSes? I'm searching through the source in an attempt to understand what needs to

> Message: 4 > Date: Thu, 27 Oct 2016 22:04:28 +0200 > From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <20161027200428.GA2177 at britannica.bec.de> > Content-Type: text/plain; charset=us-ascii > > On

We're at the point in our port of OpenVMS to x86 using LLVM to make choices on mcmodel. Given OpenVMS's history, our linker will allocate static data (ie, .data, .bss, .plt, GOT, etc.) in the bottom 32-bits of address space (ie, 00000000.xxxxxxxx). However, we support code anywhere in the 64-bit address space as PIC code (we do this on Itanium today using our own code-generator and

> > Message: 2 > Date: Sat, 29 Oct 2016 22:36:41 +0200 > From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <20161029203641.GB20270 at britannica.bec.de> > Content-Type: text/plain; charset=us-ascii >