similar to: [LLVMdev] [lld] driver and options questions

On Wed, Jan 23, 2013 at 6:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > Michael, > > I'm looking at flushing out the mach-o driver and targetinfo. > > Can we rename the "ld64" flavor to "darwin". The command line tool on MacOSX is called "ld" - just like on unix. The name ld64 is the current source repository name for the linker. Once

On Jan 24, 2013, at 2:45 AM, Michael Spencer wrote: > On Wed, Jan 23, 2013 at 6:57 PM, Nick Kledzik <kledzik at apple.com> wrote: >> I've worked through adding DarwinOpts.td new DarwinDriver class, but have some questions about wiring it up. Currently the instantiated Driver transforms the command line arguments in to "core" arguments which is passed to

I was wandering how much is the overhead of virtual function calls of TargetInfo member functions. TargetInfo handles platform-specific details, and we have target-specific subclasses of that class. The subclasses override functions defined in TargetInfo. The TargetInfo member functions are called multiple times for each relocation. So the cost of virtual function calls may be non-neglible. That

> On Mar 30, 2016, at 4:25 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: > I believe the relocation stuff that Rafael is currently working on will make this a non-issue (it will make relocation application much friendlier for the CPU).

I believe the relocation stuff that Rafael is currently working on will make this a non-issue (it will make relocation application much friendlier for the CPU). However, even in the current scheme, since the target is fixed, all the indirect call sites should be monomorphic and so there shouldn't be much branch-prediction cost (certainly nothing that would cause 1.8% performance delta for the

On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com> wrote: > I believe the relocation stuff that Rafael is currently working on will > make this a non-issue (it will make relocation application much friendlier > for the CPU). > I don't think Rafael's patch would make this a non-issue. He's making scanRelocs to create data, which would reduce the

On Fri, Apr 08, 2011 at 07:37:39AM -0400, Jack Howarth wrote: > On Fri, Apr 08, 2011 at 08:28:27AM +0200, Duncan Sands wrote: > > Hi Jack, > > > > > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > > > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > > > build fails as...

On Wed, Mar 30, 2016 at 4:25 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> I believe the relocation stuff that Rafael is currently working on will >> make this a non-issue (it will make relocation application much friendlier >> for the CPU). >> > > I don't think

On Fri, Apr 08, 2011 at 08:28:27AM +0200, Duncan Sands wrote: > Hi Jack, > > > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > > build fails as... > > what does the command > ./TargetInfo -p > return (the TargetInfo program

On Wed, Mar 30, 2016 at 5:34 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Mar 30, 2016 at 4:25 PM, Rui Ueyama <ruiu at google.com> wrote: > >> On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com> >> wrote: >> >>> I believe the relocation stuff that Rafael is currently working on will >>> make

On Wed, Mar 30, 2016 at 6:17 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, Mar 30, 2016 at 5:34 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Wed, Mar 30, 2016 at 4:25 PM, Rui Ueyama <ruiu at google.com> wrote: >> >>> On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com> >>> wrote:

Hi Jack, > Also note that under darwin10, on a EMT64-capable hardware, I get... > > ./TargetInfo -t > x86_64-apple-darwin10.5.0 > > ./TargetInfo -a > x86_64 > > ./TargetInfo -p > x86 > > So it appears that TargetInfo needs to be called with -a and not -p on darwin10. no, it is correct. The -p option is used to determine which subdirectory of the

Dear community, I have developed a backend of new 32-bit RISC ISA, which does not have unaligned memory access instructions (e.g., LWL, LWR, SWL, and SWR in MIPS). Since char and short variables are not 32-bit alignment, these variables cannot be correctly accessed. Therefore, alignment member functions, especially getCharAlign() and getShortAlign() of TargetInfo class in

On 5/1/2018 4:35 AM, Hiroyuki Chishiro via llvm-dev wrote: > Dear community, > > I have developed a backend of new 32-bit RISC ISA, which does not have > unaligned memory access instructions (e.g., LWL, LWR, SWL, and SWR in > MIPS). > Since char and short variables are not 32-bit alignment, these > variables cannot be correctly accessed. > Therefore, alignment member

Duncan, Many thanks for your comments. The core issue we're running into is this: $ GCC=/usr/bin/gcc LLVM_CONFIG=/usr/bin/llvm-config make Compiling utils/TargetInfo.cpp Linking TargetInfo ld: fatal: library -lLLVMSupport: not found ld: fatal: file processing errors. No output written to TargetInfo collect2: error: ld returned 1 exit statusAll other gyrations are attempts to shoehorn

> Are you looking in Clang's source, and that from the same 7.0 version? Yes, I am, and it’s the same version (7.0.1). “LargeArrayMinWidth” is only on the following files: TargetInfo.cpp TargetInfo.h So I still think there’s something else that makes the difference on the x86 target. Anyway, I will now investigate other targets as my temporary frontend. It is right that other targets

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

Duncan, I am unable to complile dragonegg 3.2 with FSF gcc 4.7 due the the compiler errors... GCC=/sw/lib/gcc4.7/bin/gcc-4 LLVM_CONFIG=/sw/opt/llvm-3.2/bin/llvm-config VERBOSE=1 ENABLE_LLVM_PLUGINS=1 make CPPFLAGS="-g -DENABLE_LTO -I/sw/include" /sw/lib/gcc4.7/bin/gcc-4 --version > /dev/null /sw/opt/llvm-3.2/bin/llvm-config --version > /dev/null Compiling utils/TargetInfo.cpp

Duncan, Yes, I'd been pretty much performing the same diagnosis in parallel - it seems we just don't have that libLLVMSupport library built. Last night, tried the build of clang a few different ways to get that library built - including specifying the --gcc-toolchain option. No Joy! Which of the clang/llvm source trees provides it? or is it in another source package? tools? Is there a

Hi all, Working on lld aarch64 support I came across an issue where I am not sure which would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at