search for: resetsubtargetfeatures

On Jun 6, 2013, at 8:35 PM, Tobias Grosser <grosser at google.com> wrote: > I understand that some users do not require 754 compliant floating point behavior (clang on darwin?), which means they would probably not need this change. However, it should also not hurt them performance-wise as such users would probably set the relevant global fast-math flags to reduce the precision

...erPC ABI is followed (with some deviations). Is this refering to the DarwinABI? - In a recent commit a TargetABI value and enumeration was added to PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to either ELF-variant in resetSubtargetFeatures(...) based on endianess (unless explicitly set previously). As I understand it ELFv2 is a new ABI but which ABI does ELFv1 map to? - Since isSVR4ABI() is defined as !isDarwin() it currently is possible for SVR4 and ELFv2 to be true at the same time which doesn't seem correct to me. - My underst...

...th flags. Fast math may > imply reasonably imply NEON, but the opposite direction is not accurate. > > That said, I don't think anyone would object to making VFP codegen > available under non-Darwin triples. It's just a matter of making it happen. > Hi Owen, ARMSubtarget::resetSubtargetFeatures(StringRef CPU, StringRef FS) has a check to see if the target is Darwin or if UnsafeMath is enabled to set the UseNEONForSinglePrecisionFP, but only for A5 and A8, where this was a problem. Maybe I was too conservative on my fix. Tobi, The march=arm option would default to ARMv4, while mattr=+neo...

Hi, I was recently looking into the translation of LLVM-IR vector instructions to ARM NEON assembly. Specifically, when this is legal to do and when we need to be careful. I attached a very simple test case: define <4 x float> @fooP(<4 x float> %A, <4 x float> %B) { %C = fmul <4 x float> %A, %B ret <4 x float> %C } If fooP is compiled with "llc -march=arm

...gt; No, that's the ELFv1 ABI. > > > - In a recent commit a TargetABI value and enumeration was added to > > PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and > > PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to > > either ELF-variant in resetSubtargetFeatures(...) based on > > endianess > > (unless explicitly set previously). As I understand it ELFv2 is a > > new > > ABI but which ABI does ELFv1 map to? > > I hope the above makes it clearer. > > > - Since isSVR4ABI() is defined as !isDarwin() it currently is >...

...OptLevel, &Mips::CPU64RegsRegClass : &Mips::CPURegsRegClass); return OptLevel >= CodeGenOpt::Aggressive; } +void MipsSubtarget::resetSubtarget(MachineFunction *MF) { + bool ChangeToMips16 = false, ChangeToNoMips16 = false; + DEBUG(dbgs() << "resetSubtargetFeatures" << "\n"); + AttributeSet FnAttrs = MF->getFunction()->getAttributes(); + ChangeToMips16 = FnAttrs.hasAttribute(AttributeSet::FunctionIndex, + "mips16"); + ChangeToNoMips16 = FnAttrs.hasAttribute(AttributeSet::FunctionIn...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

...deGenerator.html#llvm-powerpc-abi - David >> - In a recent commit a TargetABI value and enumeration was added to >> PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and >> PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to >> either ELF-variant in resetSubtargetFeatures(...) based on endianess >> (unless explicitly set previously). As I understand it ELFv2 is a new >> ABI but which ABI does ELFv1 map to? > > I hope the above makes it clearer. > >> - Since isSVR4ABI() is defined as !isDarwin() it currently is possible >> for SVR4 an...

...Tobi, > > The march=arm option would default to ARMv4, while mattr=+neon would force > NEON, but I'm not sure it would default to A8, which would be a weird > combination of ARM7TDMI+NEON. > > There are two things to know at this point: > > 1. When the execution gets to resetSubtargetFeatures, what CPU has it > detected for your arguments. You may also have to look at ARM.td to see if > the CPU that it got detected has in its description the feature > "FeatureNEONForFP". > > 2. If the CPU is correct (Cortex-A*), and it's neither A5 nor A8, do we > still w...