similar to: ARM Static Base Register

Hi, We currently have a downstream patch (attached) which implements some new addressing modes that enable position-independent code for small embedded systems. Is this something that would be accepted upstream? I think the ARM backend changes are fairly uncontroversial, but the clang changes introduce a lot of ROPI/RWPI specific changes in otherwise target-independent code. If the clang changes

Oh, I wasn’t really thinking about devices without an MMU where the addresses are physically separated. Makes sense. This reminds me of rwpi on ARM; it has a sort of similar scheme of referring to data indirectly through a pointer, but it also changes the ABI to keep the pointer in a reserved register. -Eli From: Evandro Menezes <evandro.menezes at sifive.com> Sent: Friday, March 20, 2020

Hi, Sam. I think that it's a fair comparison. Keep in mind that the GP is only used to reach global variables of local scope and the GOT, where the address of global variables of global scope reside. This model assumes that the distance between the GP and the global data area, GOT and local scope variables is defined at link time. __ Evandro Menezes ◊ SiFive ◊ Austin, TX > On Mar

Hi Sjoerd, For ISel, I think having a separate register class will give you less headache. I wondering if you could get away with not touching the instructions descriptions at all, instead defining external pattens for the FullFP16 case, like so: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins SPR:$Sm), IIC_fpCVTSH, "vcvtb",

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

I am running R 2.1.1 on a Mac g5 under Mac OS 10.4.2. I have an xyplot with a single conditioning variable (8 levels) . Here is the code for the conditioning variable used in the formula argument of xyplot: factor( drugauthoryear, levels = c( 'bupicapogna1999', 'levobenhamou2003', 'ropicapogna1999',

I would like to revive this thread, as I am struggling a lot with the FP16 implementation in the ARM backend. My implementation in https://reviews.llvm.org/D38315 is finished (except one case), but a more robust alternative implementation was suggested. One can indeed argue that my current implementation is a bit fragile, because it involves manually patching up the isel dags for a few cases. The

I’ve had another look, and some of the failing tests don’t use temporary files, so I don’t think this is a case of tests having side-effects. Instead, I’ve noticed that in the build log (http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6552/steps/build-unified-tree/logs/stdio), llvm-tblgen.exe is built (my patch modified it), but the table-generation steps of the

Hi, I'm trying to compile half precision program for ARM, while it seems LLVM fails to automatically generate fused-multiply-add instructions for c += a * b. I'm wondering whether I did something wrong, if not, is it a missing feature that will be supported later? (I know there're fp16 FMLA intrinsics though) Test programs and outputs, $ clang -O3 -march=armv8.2-a+fp16fml

Hi Oliver, Thanks for trying this. Could you file a different PR for each of the problem you found and reference the umbrella PR: http://llvm.org/PR35347? <http://llvm.org/PR35347?> Thanks, -Quentin > On Nov 17, 2017, at 8:17 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > One more reproducer, this time with small (<64bit) values

Thanks all. Amara, could you take a look? > On Nov 20, 2017, at 3:06 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > I’ve raised: > https://bugs.llvm.org/show_bug.cgi?id=35359 <https://bugs.llvm.org/show_bug.cgi?id=35359> > https://bugs.llvm.org/show_bug.cgi?id=35360 <https://bugs.llvm.org/show_bug.cgi?id=35360> >

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s

Hi Oliver, There would be no problem if both the Map and the Vector indeed contained (Key,Value) pairs. To save space, Map entries do not contain Value but instead an unsigned index into the Vector: /// The values are kept in a std::vector and the /// mapping is done with DenseMap from Keys to indexes in that vector. After an element is erased from the Vector all indices greater than the

Thanks for reply. I was using LLVM 8.0. Let me try trunk and will let you know if it works. On Wed, Sep 4, 2019 at 11:19 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Hi, > Which version of Clang are you using? I do get a "vfma.f16" with a recent trunk build. I haven't looked at older versions and when this landed, but we had an effort to plug the remaining

Hi Manoj, Not too late at all, we have not got to that point of the work yet. Are there examples of this kind of build setup that are available publicly? I think I understand the problem but it'd help to see one in action. To see if there are any other Arm extensions that are already being added like this and whether those systems support GCC and how. Thanks, David Spickett.

Hi there, I've created a bug on llvm: http://www.llvm.org/bugs/show_bug.cgi?id=9582 Basically, ARM, Thumb and data mapping symbols should have been exported in the ELF file, so the linker can work correctly. I can do the change and create some test cases, but I haven't been paying much attention to recent MC developments. Is ArmAsmPrinter the place to change for that, or is there an MC

To give an update here, we actually are not missing a mapping. The code complains because we are copying around a fp16 into a gpr32 and that shouldn’t be done with a copy (default mapping). I extended the repairing code to issue G_ANYEXT in those cases instead of asserting. However, now, I have to teach instruction select about those ANYEXT otherwise we’ll fallback in that case. But that’s a

[AMD Public Use] Hi Oliver, I get rid of the warnings by explicitly type-casting it to struct*, and still get similar results. ####################################################### struct P { float f1; float f2; float f3[3]; float f4; }; void foo(struct P* p1, struct P* p2) { p1->f2 = 1.2; p2->f1 = 3.7; } int callFoo() { struct P p; foo(&p,

ARM backend emits different eabi build attributes based on the ISA variant the target supports or whether certain fast-math options are passed on the command line. For example, these are the attributes that have different values depending on whether -ffast-math is passed to clang: $ clang -target armv7-linux-gnueabi -ffast-math (with -ffast-math) .eabi_attribute 20, 2 @ Tag_ABI_FP_denormal

Hi Manoj, I tried a few other options myself: * function 'target' attribute - the list of extensions this supports isn't complete and it doesn't enable the ACLE macros needed for intrinsics * manually defining ACLE macros - this allows intrinsics and is additive but assumes that you're not relying on codegen to emit instructions. I don't think it helps the bug linked