search for: mips64r2

Hi Eric, The main thing we need to fix is that the selection between ELF32/ELF64 needs to depend on the ABI being N64 and not on whether we used a mips-linux-gnu triple versus a mips64-linux-gnu triple. So 'clang -target mips-linux-gnu' -mips64r2 -mabi=64' should produce an ELF64 and 'clang -target mips64-linux-gnu -mips32r2 -mabi=32' should produce an ELF32. In terms of code, we need to get the ABI name to createMipsELFObjectWriter(). One of your commits on Monday (r227102) seems to make this a lot easier than it was looking l...

The term "target" is somewhat overloaded. When llvm-config tells you it was built with the X86 target, that actually includes a variety of closely related architectures, such as x86_64, i386, and so on. Within the x86_64 architecture, there are many individual processor implementations that LLVM understands, such as Skylake, Bulldozer, and many many more. What *clang* means by

...to properly instantiate TargetOptions in MC layer? Hi Eric, The main thing we need to fix is that the selection between ELF32/ELF64 needs to depend on the ABI being N64 and not on whether we used a mips-linux-gnu triple versus a mips64-linux-gnu triple. So 'clang -target mips-linux-gnu' -mips64r2 -mabi=64' should produce an ELF64 and 'clang -target mips64-linux-gnu -mips32r2 -mabi=32' should produce an ELF32. In terms of code, we need to get the ABI name to createMipsELFObjectWriter(). One of your commits on Monday (r227102) seems to make this a lot easier than it was looking l...

- my old email address. The ISA_* classes might not be the best choice for this. There's an overall hierarchy and ordering to the ISA_* classes since they represent the generations of the MIPS ISA. If these extensions are available in Loongson chips based on MIPS32r1 and MIPS32r2 for example, it becomes difficult to describe with ISA_* classes without duplicating instruction definitions or

Hi Akira, > I am running into a problem when I turn on post-RA scheduler with mode > "ANTIDEP_CRITICAL" for mips. > I'd appreciate if someone could explain what is going wrong here. All these passes are pretty sensitive to correct register liveness information. As a first step I'd check whether machine verifier reports no errors here. -- With best regards, Anton

On 09/27/2015 06:41 PM, Vasileios Kalintiris wrote: > Hi Richard, > > Clang doesn't have support for MIPS I. The trap-on-condition instructions were added in MIPS II and they should work fine. This is why it works with ".set mips32r2". > > Which version of the ISA did you specify when you used the integrated assembler? > > Thanks, > Vasileios > > Hi

...find a > general solution to this is very high. I also know of some impending work > that it likely to make matters worse. I want to be able to, for example, ask > the TargetTuple whether I am targeting a 64-bit ISA and whether I'm supposed > to treat it as a 32-bit ISA (e.g. O32 on MIPS64R2) in many areas of LLVM > (including those where MipsSubtarget and similar are not available) and be > able to rely on the answer. At the moment, we incorrectly conflate 'is it a > 64-bit ISA?' with 'is the CPU 64-bit?' as well as 'is the ABI 64-bit?' with > '...

...-verify-machineinstrs, it complains that there are instructions after terminator instructions. It seems that these error messages are printed because the verifier does not understand that mips has delay slots, not because it has detected any true violations. $ llc macroblock.llvm.mips64el.ll -mcpu=mips64r2 -O3 -o macroblock.s -mattr=n64 -verify-machineinstrs # After PreEmit passes # Machine code for function start_macroblock: Post SSA BB#0: derived from LLVM BB %entry Live Ins: %A0_64 %T9_64 %RA_64 %S3_64 %S2_64 %S1_64 %S0_64 BEQ %A0<kill>, %ZERO, <BB#2> NOP Successors a...

...re is small structures in vararg functions and this turns out to be broken on GCC too. > In this case, it would help too if you could provide some release > testing for MIPS. I'll be testing natively for MIPS32, and MIPS32r2 (both endians). I'll also be testing cross-compilation for MIPS64r2 (both endians) and MIPS64r6 (both endians). > Are you planning on back-porting these patches to 3.5 for personal use, > even if they aren't going to be included in the official release? If one of our customers requires it, yes. Otherwise, I'll stick to official releases. Sorry for t...

...ders mips64-linux-gnu to be a 64-bit architecture using the N64 ABI. This is a problem because having a 64-bit CPU does not require the ABI to be N64 or even 64-bit (N32/N64). It's valid to produce O32 code for a 64-bit processor (and triple) and many of my test systems (e.g. 32-bit Debian on a MIPS64R2 processor) actually need this since the host triple detected by config.guess is mips64-linux-gnu. As things stand, attempting to emit O32 code on a mips64-linux-gnu host crashes the compiler unless you cross-compile by adding '-target mips-linux-gnu'. My 'native' LLVM releases are a...

Hi all, The 3.7 release branch was created from trunk at r242221 today (around 10:40 pm UTC). Branch policy: - Any doc changes can go in. Updates to the release notes are highly encouraged, and should be committed directly to the branch. - All other patches should be approved by the release manager (me) and the appropriate code owner. To get a change merged, commit it to trunk, and then reply

Hi all, we have several features in Mips that are dependent on target abi. A recent commit(r224492) introduced a new -target-abi option to TargetOptions struct that provides access to abi string. This info is stored in MCSubtarget class(ARMSubratget in this case) and distributed to other libraries. Unfortunately, for Mips we need this info in other classes that don't have access to MCSubtarget

I am running into a problem when I turn on post-RA scheduler with mode "ANTIDEP_CRITICAL" for mips. I'd appreciate if someone could explain what is going wrong here. This is the basic block before post RA scheduling (at PostRASchedulerList.cpp:322): *(gdb) #3 0x0000000000ed3d26 in runOnMachineFunction (this=0x20aa470, Fn=...) at lib/CodeGen/PostRASchedulerList.cpp:322 322

...ct/Loong-Language/loong-llvm/build/bin/clang-7 -cc1 -triple mips64el-redhat-linux -emit-llvm -disable-free -main-file-name e203_core.loong -mrelocation-model pic -pic-level 1 -mthread-model posix -mdisable-fp-elim -fmath-errno -no-integrated-as -mconstructor-aliases -fuse-init-array -target-cpu mips64r2 -target-feature -noabicalls -target-abi n64 -mfloat-abi hard -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /home/zhaixiang/project/Loong-Language/e200_opensource/rtl/e203/core/e203_core.gcno -resource-dir /home/zhaixiang/project/Loong-Language/loong-llvm/build/lib/clang/7.0.0 -...

I'm cross-compiling for MIPS. The test-case is as simple as it can be: void foo() {} $clang -target mips64-octeon-linux -c -B path/to/cross/compiled/mips/assembler a.c And then I look at the object file: $ nm a.o 0000000000000020 t $tmp0 0000000000000000 T foo I would like to know what "$tmp0" is. Furthermore, if I pass -g to clang, I see a whole bunch of such symbols. Some of

Hi, I'd like to propose the following patches for inclusion in Clang 3.5.1. Proposed clang patches: * r213769 - Fix test/Driver/cl-x86-flags.c by providing explicit -target * r214025 - [Driver][Mips] Check output of -dynamic-linker arguments by the Clang driver * r214662 - [Mips] Add the `mips64-linux-gnu` target to the test case to check `in128` type handling. *

Hi LLVM developers, GCC[1] is able to use Loongson ISA[2] for instruction selection: $ cat hello.c #include <stdio.h> int main(int argc, char *argv[]) { printf("Hello World\n"); return 0; } $ gcc -O0 -S hello.c $ cat hello.s .file 1 "hello.c" .section .mdebug.abi64 .previous .nan legacy .gnu_attribute 4, 1 .abicalls

...MIPS CPU names. This list can be found in the "clang/lib/Basic/Targets/Mips.cpp". mips1 and mips5 accepted by Clang, but unsupported by code generator. I'm going to remove them from this list. mips1, mips2, mips3, mips4, mips5, mips32, mips32r2, mips32r3, mips32r5, mips32r6, mips64, mips64r2, mips64r3, mips64r5, mips64r6, octeon, octeon+, p5600 R3000 is a CPU implements mips1 instruction set architecture. Unfortunately you cannot generate a code for this CPU using Clang. -- Simon Atanasyan Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789...

Hi Daniel, > (from the context, you might have meant 'tuple' where you've written > 'triple'. I'm answering based on the assumption you meant 'triple') > > I did mean what I wrote. > The GNU triple is already used as a way of encoding a large amount of the > target data in a string but unfortunately, while this data is passed > throughout

Hi Eric, Thanks for getting back to me on this. > I'm not sure I agree with the basic idea of using the target triple as a way of > encoding all of the pieces of target data as a string. I think in a number of > cases what we need to do is either open up API to the back end to specify things, > or encode the information into the IR when it's different from the generic triple.