search for: armv7k

I noticed this in Xcode 4.2. My best guess is that armv7f adds some floating-point support and armv7k is security extensions (at least based on historical nomenclature). Are these Apple specific architecture definitions? Is there any developer documentation available? Cheers, Joe Abbey Software Architect Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 479...

...2 support, which should be fairly easy to adapt to the ELF (or COFF) world and be generally useful. This involved changing some generic code in ways I'll discuss below. Then there's the specific ABI we chose, which isn't quite the same as AAPCS since it was designed in conjunction with armv7k so that IR could be compiled to be compatible with arm64_32. Since people do use third-party compilers based on LLVM having it upstream is expected to be a good thing. Finally we have a few passes that translate the necessarily platform-specific parts of armv7k IR to arm64_32. Things like NEON int...

...eans that when a struct gets loaded or stored directly it needs to be repacked. Completely tractable, but not pretty. Also, we couldn't do that anyway because the ABI is now very much set in stone (actually has been in that regard since the very first watch came out -- we translate bitcode for armv7k to arm64_32 which is hopelessly doomed if the DataLayouts don't match). And thanks for the pointers on AMD; I'll take a look at those properly and see what we can learn. Cheers. Tim.

.../drive.google.com/file/d/11Ngst9FOnVL4fWYlKalzoFXL--B1SaOb/view?usp=sharing> > > My ld version is: > > ➜ ld -v > @(#)PROGRAM:ld PROJECT:ld64-530 > BUILD 18:57:17 Dec 13 2019 > configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em > LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23) > TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11) > > Since that said it was using LTO from Xcode I thought that might be the problem - but when I run cla...

This is usually a problem that is not using llvm-ar. I cannot reproduce this problem with either llvm 10.0 or TOT version. Which linker version are you using? You can also try pass "-Wl,-debug_snapshot" to the command where the error produces and then locate the "*.ld-snapshot" in /tmp directory and attach that as a reproducer. Steven > On Jul 22, 2020, at 8:41 AM, Teresa

On Fri, 1 Feb 2019 at 19:25, Eli Friedman <efriedma at quicinc.com> wrote: > > Alternate address-spaces still have just one pointer size per space as > > far as I'm aware. If that's 64-bits we get efficient CodeGen but > > loading or storing a pointer clobbers more data than it should, if > > that's 32-bits then we get poor CodeGen. > > I was

...gst9FOnVL4fWYlKalzoFXL--B1SaOb/view?usp=sharing> >> >> My ld version is: >> >> ➜ ld -v >> @(#)PROGRAM:ld PROJECT:ld64-530 >> BUILD 18:57:17 Dec 13 2019 >> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em >> LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23) >> TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11) >> >> Since that said it was using LTO from Xcode I thought that might be the problem - bu...

...ed to make it work I think. > I'm not sure I follow the difference between [2 x i32] and i64: if they both go into a single register, why do you need both? Or is this necessary to support your automatic translation pass? Yep, it's entirely because we need to support code generated for armv7k. On that platform [2 x i32] and i64 have different alignment requirements on the stack; [2 x i32] would be used for struct { int32_t val[2]; }, i64 would be used for struct { int64_t val; }. But because AArch64 AAPCS puts more data in registers, some of these args generated for the stack go in regi...