similar to: [LLVMdev] adding new target to configure script

Hello everyone! I've started to implement a ColdFire backend, but there are some troubles during configuring: $ ../llvm/configure --enable-targets=x86,x86_64,coldfire ... ... ... checking whether byte ordering is bigendian... no configure: error: Unrecognized target coldfire configure: error: ../../../llvm/projects/sample/configure failed for projects/sample I've added ColdFire to : 1)

On Fri, Feb 1, 2013 at 4:01 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: >> Hello everyone! >> >> I've started to implement a ColdFire backend, but there are some troubles >> during configuring: >> >> $ ../llvm/configure --enable-targets=x86,x86_64,coldfire >> ... >>

On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: > Hello everyone! > > I've started to implement a ColdFire backend, but there are some troubles > during configuring: > > $ ../llvm/configure --enable-targets=x86,x86_64,coldfire > ... > ... > ... > checking whether byte ordering is bigendian... no > configure: error: Unrecognized target

Here's how I did things, back when I got to write my own infrastructure. It's still O(n^2) in the worst case, but *much* quicker in the expected case. Number all the basic blocks, 0 to n-1 and build a vector mapping from integer to block. Requires O(n) time and space. For each block, compute the set containing it's dominance frontier, based on Figure 10 of * * *Efficiently

I tried building LLVM 2.1 with no real target CPU backends enabled, just the C backend, by hacking the configure script slightly: --- /home/foad/llvm/llvm-2.1/configure 2007-09-17 22:37:52.000000000 +0100 +++ configure 2007-12-13 10:29:41.000000000 +0000 @@ -4762,7 +4762,7 @@ done ;; esac -TARGETS_TO_BUILD="CBackend MSIL $TARGETS_TO_BUILD"

You need to add your target to autoconf/configure.ac. Here are the directions from http://llvm.org/docs/WritingAnLLVMBackend.html To get LLVM to actually build and link your target, you need to add it to the TARGETS_TO_BUILD variable. To do this, you modify the configure script to know about your target when parsing the --enable-targets option. Search the configure script for TARGETS_TO_BUILD,

I am trying to build cross compiler for custom processor (say XYZ) but on compilation it is giving error llvm-build: error: invalid native target: XYZ (not in project) I have tried configuring like these 1. ./configure --target=XYZ 2. ./configure --target=XYZ --enable-targets=XYZ 3. ./configure --enable-targets=XYZ But every time it is not recognising the XYZ processor. What could be the

any suggestions on the following gratefully welcome, I have a dataframe, which I am subsetting via labels atpi[, creativity] where (for example) atpi = as.data.frame(matrix(1:50, ncol = 5, nrow = 10)) names(atpi) = c("Q1", "Q2", "Q3", "Q4", "Q5") and creativity = c("Q1", "Q3", "Q4") I want to add an extra column

Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to generate the patch file against revison 167719 ? Thanks in advance. On

Preston, thanks for the explanation and patch. Now it's printing the direction and distance values. On Tue, Nov 13, 2012 at 12:22 PM, Preston Briggs <preston.briggs at gmail.com>wrote: > Erkan, you're right. Sorry about that. > Attached is the most recent version. > > Preston > > > > Hi Preston, >> I am trying to use DA as well. I used your example

On 13.11.2012, at 10:46, erkan diken <erkandiken at gmail.com> wrote: Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to

Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.

Hi I am interested in developing a new target for LLVM and wanted to check where my new code should reside. Should I just add a new sub-directory to lib/Targets and populate that with the necessary files? I am using ARM as a template, as I am most familiar with that architecture, so I assume copying files from that directory is a good starting point. I have tried a trivial build of a new

> On Sep 10, 2018, at 5:25 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Sep 10, 2018, at 5:11 PM, Preston Briggs <preston.briggs at gmail.com <mailto:preston.briggs at gmail.com>> wrote: >> >> The phi instruction is irrelevant; just the way I think about things. >> The question is if the allocator believes that t0 and t2

Thanks. More below. > On Jul 3, 2019, at 12:06 PM, Justin Clift <justin at postgresql.org> wrote: > > Not sure personally, as I've not touched the libcxx source before. Looking > at line 876 for libcxx/include/chrono, gives this: > > https://github.com/llvm/llvm-project/blob/d2298e74235598f15594fe2c99bbac870a507c59/libcxx/include/chrono#L876

Yes, I quite liked the things I've read about the PBQP allocator. Given what the hardware folks have to go through to get 1% improvements in scalar code, spending 20% (or whatever) compile time (under control of a flag) seems like nothing. And falling back on "average code" is a little disingenuous. People looking for performance don't care about average code; they care about

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.

Hi, Using Chaitin's approach, removing a copy via coalescing could expose more opportunities for coalescing. So he would iteratively rebuild the interference graph and check for more opportunities. Chaitin was also careful to make sure that the source and destination of a copy didn't interfere unnecessarily (because of the copy alone); that is, his approach to interference was very

Here's the current code (abstracted a bit) const Instruction *Src, const Instruction *Dst, // make sure they are loads and stores, then const Value *SrcPtr = getPointerOperand(Src); // hides a little casting, then Src->getPointerOperand const Value *DstPtr = getPointerOperand(Dst); // ditto // see how underlying objects alias, then const GEPOperator *SrcGEP =

On 11/02/2012 11:02 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Tobias Grosser" <tobias at grosser.es> >> To: "preston briggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November