similar to: LLD: Possible optimization for TargetInfo

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

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 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 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 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).

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:

On Wed, Mar 30, 2016 at 6:42 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > 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

Hi, Rafael took some measurements to try to investigate the effect of the local symbols changes. I've been taking a look at the measurements he got and there were some interesting things we noticed. For starters, in the range of revisions tested (r263214 through r263471), we found that the commit for --build-id was the most noticeable, with slowdowns from 7% to 23% (note: these were

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 lld takes over, the term ld64 won't mean anything. I've worked through adding DarwinOpts.td

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 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

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

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

On Fri, Dec 07, 2012 at 06:20:37PM +0100, Duncan Sands wrote: > Hi Jack, this occurs because you compiled LLVM with clang (right?) and > dragonegg is compiled with the same flags used to compile LLVM (it is > an llvm-config bug in my opinion that llvm-config output includes these > kinds of optional flags). Duncan, Yes. I believe both fink and MacPorts now default to the clang