similar to: Incorrect Cortex-R4/R4F/R5 ProcessorModel in ARM.td

I'm trying to create a simplified 2 slot VLIW from an OR1K. The codebase I'm working with is here <https://github.com/openrisc/llvm-or1k>. I've created an initial MyTargetSchedule.td def MyTargetModel : SchedMachineModel { // HW can decode 2 instructions per cycle. let IssueWidth = 2; let LoadLatency = 4; let MispredictPenalty = 16; // This flag is set to allow the

Hi Bradley, I was doing some performance analysis for ARMv7 (cortex-a9) and I noticed that one of my benchmarks degraded by 93%. I have tracked the regression down to the following commit by you: / //commit 7c1b77248baaeafec5d6433c3d1da9a2e2b69595// //Author: Bradley Smith <bradley.smith at arm.com>// //Date: Mon Nov 16 11:10:19 2015 +0000// // [ARM] Introduce subtarget features per

Thanks Bradley. I see that the features set in /ARM.td/ get written to the generated file /<build>/llvm/lib/Target/ARM/ARMGenSubtargetInfo.inc./ Here the ProcA9 features appear in /ARMFeatureKV/ table: /{ "a9", "Cortex-A9 ARM processors", { ARM::ProcA9 }, { *ARM::FeatureFP16* } }, /With your change, the features for ProcA9 in the above entry are empty.//This

I'm trying to enable/disable a target feature through clang. Here is how my target looks like // Esencia subtarget features //===----------------------------------------------------------------------===// def FeatureMul : SubtargetFeature<"mul", "HasMul", "true", "Enable hardware multiplier">; def FeatureDiv

Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some

+ Evgeny We have a jump threading pass downstream for this that we would love to upstream. I believe Evgeny was working on exactly this, i.e. preparing it for upstreaming. ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> Sent: 23 September 2020 19:16 To: Phipps, Alan <a-phipps

On Apr 26, 2013, at 3:53 AM, Martin J. O'Riordan <Martin.ORiordan at movidius.com> wrote: > I am migrating the llvm/clang derived compiler for our processor from the > v3.1 to v3.2 codebase. This has mostly gone well except that instruction > latency scheduling is no longer happening. > > The people who implemented this previously sub-classed 'ScheduleDAGInstrs'

Hi Sjoerd We (at Huawei) also have a pass for this. Originally we implemented this back in 2018 and meant to upstream it, but there were some issues with the implementation that required some changes in the code. We started revising it,a few weeks ago. I thought now that there are multiple options, maybe we can discuss our approaches, and see if there is a preference in the community for one

It is my understanding that the implementation for jump-threading in LLVM is not presently able to effectively optimize code containing a state-machine implemented using a loop + switch. This is the case, for example, with the Coremark benchmark function core_state_transition(). Bug 42313 was filed to address this in 2019: https://bugs.llvm.org/show_bug.cgi?id=42313 It appears that GCC

Hi, Alan Thanks for making it clear. But I was more confused now :( I tested on a simple program and used both gcov and lcov to get branch coverage. The code and build commands as below: *Example simple.cc* #include <string> // If not comment this line, the branch coverage won't reach to 100% // #include <iostream> int main(int argc, const char* argv[]) { std::string str =

Hi, Alan Really very excited to receive your email and sorry to be slow replying, it has been exceptionally busy over the last few days ;( Your explanation made the problem clear to me. So gcov branch coverage should be called condition coverage and clang region coverage is branch coverage in fact(also known as *decision/C1*), right? And llvm/clang will support all the following coverage

Dear all, Some benchmarking experimentation I`ve done recently -- all on AArch64 -- has shown that it might be beneficial for all AArch64 targets to have a positive LoopMicroOpBufferSize, whereas the default that applies to all ISAs seems to be zero. Although I`ve tried going as far down the rabbit hole as I can, I haven`t found a way to set DefaultLoopMicroOpBufferSize on a per-ISA basis or

+ Vedant Hi Hal, thanks. I apologize if my answers aren't as thorough as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under

Hi, llvm/clang experts I need to get the branch coverage for some testing code. But i found gcov can't give a expected coverage which may count some 'hidden branch' in (See stackoverflow answer <https://stackoverflow.com/questions/42003783/lcov-gcov-branch-coverage-with-c-producing-branches-all-over-the-place>). Instead, I turn to use clang and the 'source-based code

Vedant Kumar asked me to post my design thoughts concerning branch coverage at llvm-dev since there is general interest. My team at Texas Instruments is developing an embedded ARM C/C++ compiler with LLVM. I would like to enhance LLVM's code coverage capability with branch condition coverage (for C/C++), similar to GCC/GCOV support for branch coverage. This is useful for TI, and I think

Hi All, I'd like to improve the way MPD (and other players) switches between tracks. I'd like something like crossfade but without any fading. I'd like the player to just overlap the end of one track with the beginning of the next track to provide a nice transition. Crossfading in MPD doesn't work for me since it just ramps the volume up/down over a fixed time and some tracks

Hi Micah, > In X86InstrInfo.td for Call Instructions, it mentions that Uses for > argument registers are added manually. Can someone point me to the > location where they are added as the comment doesn't reference a > where or how? the register uses are added by the function X86TargetLowering::LowerCall() during the DAG Lowering phase. This is the relevant code segment: // Add

Hello list, this is the communication between an Aastra 5000 PBX and Asterisk, where the Aastra makes a call to Asterisk. For some reason, Asterisk responds with 401-Unauthorized and I don't know why. Calls go well with Panasonic PBX, Avaya PBX, Alcatel-Lucent PBX but NOT with this Aastra. A1.A1.A1.A1 = IP-address Asterisk PBX AS.AS.AS.AS = IP-address Aastra PBX Aastra PBX makes a call

lvm 3.7.0 treats pentium dual core ( cpu family 6 model 23 ) as "penryn" cpu, which triggers a serious bug : - crashs in openGL programs when llvm is used by mesa package, llvm will produces binary code with SSE4 instructions, which is not compatible with pentium dual core, because this CPU doesn't support SSE4 instructions ( bad cpu opcodes ), with llvm 3.6.2 this bug doesn't

Hi all! I tried to use CentOS5 on an IBM Thinkpad R52 which has an Intel PRO/Wireless 2915ABG Mini-PCI Adapter installed. I downloaded the firmware from the DAG-Repo (afaik 3.0.0) and added a "alias eth1 ipw2200" to modules.conf. After the module was loaded successfully (including the firmware) I was able to configure the card. For simplicity I didn't use any encryption. My