Sedat Dilek via llvm-dev | 26 Jun 10:45 2016

[LLVM/Clang v3.8.1] Missing Git branches/tags and source-tarballs?

Hi Tom, Hi Anton,

the first I had in mind was...
"Another (LLVM/CLang) realease - a new drama!"
( See Byron Katie "The work". )

I know SVN is your 1st development platform.
Personally, I prefer Git and use the LLVM/Clang mirrors on GitHub.

Unfortunately, I am missing a "release_381" branch at all on the
GitHub repositories.

I looked through the llvm-commits [1] and I only see two emails with
the subject...

"Creating release candidate final from release_381 branch"

[test-suite] r273407 - Creating release candidate final from
release_381 branch   Tom Stellard via llvm-commits
[lld] r273414 - Creating release candidate final from release_381
branch   Tom Stellard via llvm-commits

So, how should I know which is the corresponding SVN-commit-id for
tagging myself in my local [llvm | clang | compiler-rt]
Git-repositories?

Which files have to be changed to get a correct version-string when
invoking "clang -v" or 'clang --version" (here: "3.8.1")?
( I had that problem with "3.8.0rc3" in my local Git repos, I got
displayed "3.8.0" as a version-string )
(Continue reading)

Get variable declaration type as String sometimes gives me wrong types.

Hello again,

I have implmented an AST Visitor using clang. In my visitor exists the following function.

virtual bool VisitVarDecl(VarDecl *var) 
    {
        numVariables++;
        string varName = var->getQualifiedNameAsString();
string varType = var->getType().getAsString();
cout << "VisitVarDecl: " << varName << " of type " << varType << "\n";        
APIs << varType << ", ";
        return true;
    }

Now the problem is that whenever a variable declaration exists in my code the visitor detects it but sometimes returns me the wrong type.
for Example if the type is size_t it will return int. if the size is char32_t it will again return int. 
I just want it to return whatever the type is even if is imaginary for example
asdasd x;

Thank you, 
Andreas Georgiou
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

ASTVisitor Tutorial Makefile

Can somebody provide me with a makefile to compile this official tutorial?

Thank you.
Andreas Georgiou


_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Jordan Rudd via llvm-dev | 25 Jun 04:03 2016

Unit testing generated IR

Hi,

I've been using llvm as part of a self-education project and I'm trying to write a simple compiler. I'm curious about the best way to go about validating the IR my compiler produces. On one hand, I can always produce a bc file and run the interpreter on it from the command line, but I'm wondering if there's a way I can do this programmatically in unit tests. For example, is there any way to run the code in a module I've produced through an interpreter and see the results from a unit test (without running CreateProcess on lli)? Thanks for your time,

Jordan
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Shashank Sinha via llvm-dev | 24 Jun 14:59 2016

Newbie developer looking to contribute

Hi,

I am currently looking for some development project in the open source community. I went through the community wiki and mailing list to find if there existed any resource I could use to start working on something interesting. After some reading and thinking, I am hoping someone can help me understand the process of initiation of a new developer in the community from selecting a bug/task/project to bringing it to the logical end.

I am versed in C, Java and Python. I consider myself a novice and hope someone can help me find answers to the following questions:

1. How do I get started so I can select a task to work on ? Should I interact with program, try to understand some code and then start working on some bug or should I start with some feature request and then attack the code directly, understanding as I code ?

2. Whom should I communicate with before starting any work on the task? I do not want duplication of effort and ensures my effort is fruitful for the project.

3. What is the usual way of ensuring I am making progress with my effort in the field? Should I share task milestones with select few or share the final patch in one go ?

Thanks for giving me direction and helping me out.

Regards,
Shashank Sinha

--
God created man, man created computer. Hence God created computer.
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
vivek pandya via llvm-dev | 25 Jun 19:33 2016

Tail call optimization is getting affected due to local function related optimization with IPRA

Hello LLVM Community,

To improve Interprocedural Register Allocation (IPRA) we are trying to force caller
saved registers for local functions (which has likage type local). To achive it
I have modified TargetFrameLowering::determineCalleeSaves() to return early for
function which satisfies if (F->hasLocalLinkage() && !F->hasAddressTaken()) and
also reflecting the fact that for local function there are no caller saved registers
I am also changing RegUsageInfoCollector.cpp to not to mark regiseters as callee
saved in RegMask due to CC with follwoing change in code:

if (!F->hasLocalLinkage() || F->hasAddressTaken()) {
      const uint32_t *CallPreservedMask =
        TRI->getCallPreservedMask(MF, MF.getFunction()->getCallingConv());
      // Set callee saved register as preserved.
      for (unsigned i = 0; i < RegMaskSize; ++i)
        RegMask[i] = RegMask[i] | CallPreservedMask[i];
    } 

For more details please follow following link.

Now consider following bug due to forcing caller saved registers for local function
when IPRA enable:

void makewt(int nw, int *ip, double *w) {
  ...
  bitrv2(nw, ip, w);
}

here bitrv2 is local fuction and for that when IPRA enable callee saved registers
are set to none. So for that function following is set of collbered register as
per regmaks collected by RegUsageInfoCollector pass.

Function Name : bitrv2
Clobbered Registers:
AH AL AX BH BL BP BPL BX CH CL CX DI DIL EAX EBP EBX ECX EDI EFLAGS ESI ESP RAX
RBP RBX RCX RDI RSI RSP SI SIL SP SPL R8 R9 R10 R11 R12 R13 R14 R15 R8B R9B R10B
R11B R12B R13B R14B R15B R8D R9D R10D R11D R12D R13D R14D R15D R8W R9W R10W R11W
R12W R13W R14W R15W

How ever caller of bitrv2, makewt has callee saved registers as per CC, but this
code results in segmentation fault when compliled with O1 because makewt has value
of *ip in R14 register and that is stored and restore by makewt at begining of call
but due to tail call optimization following code is generated and here bitrv2 does
not preserve R14 so whwn execution returns to main (which is caller of makewt)
value of *ip is gone from R14 (which sould not) and when main calls makewt again
then value of *ip (R14) is wrong and result into segmentation fault.

Assembly code of makewt:
  _makewt:
  ...
  popq  %rbx
  popq  %r12
  popq  %r13
  popq  %r14
  popq  %r15
  popq  %rbp
  jmp _bitrv2                 ## TAILCALL

There is one more case of faluire due to local function related optimization.
I am analysing that (sorry for taking more time but I am not much good at assembly).

I need some hints for how to solve this. If you feel some problem with my analyses
please let me know if you want me to send generated .s file and source .c file.

Sincerely,
Vivek
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Roman Gareev via llvm-dev | 25 Jun 16:08 2016

Re: [isl-dev] Application of a piecewise quasi-affine transformation to a band node

> I'm attaching what I managed to dig out.
> It's a preliminary patch that is not ready for inclusion,
> but you can check if the interface looks like it might work
> for you.
>
> There are still several issues to resolve.
>
> One issue is what to do with anchored trees.
> The elements in the subtree that refer to the original
> band need to be modified as well to refer to the modified band.
> If the transformation is injective, then it is always possible
> to compute the required left-inverse that is needed to transform
> those elements.
> One question is whether this left-inverse should indeed be computed
> by isl_schedule_band_band_transform_pw_multi_aff or whether it should
> be speficied by the user.  The user may have easy access
> to a simple form of the inverse.
> If the user is allowed to specify an inverse, then this could
> also be done in cases where the transformation is not injective.
> It's not clear if there are any use-cases for that, though.
> In fact, it's not even clear if you would ever want to transform
> a band node with an anchored subtree in the first place.
> The attached patch completely ignores this issue,
> but this should obviously be fixed first.
>
> Another issue is what to do with properties such as
> permutability and coincidence.  The attached patch
> simply clears all properties.  For some special cases
> of transformations such as permutations, it would be
> possible to transform the properties accordingly,
> but I don't think it's possible in general.
>
> Since isl_schedule_band_band_transform_pw_multi_aff accepts
> a piecewise affine transformation, it is possible that
> the transformation _removes_ some parts of the domain.
> I think this should not be allowed, meaning that
> isl_schedule_band_band_transform_pw_multi_aff would have
> to check this condition.  An alternative would be
> to introduce an isl_schedule_band_band_transform_multi_aff
> instead, which would not have to worry about this issue.

Thank you for the detailed explanation and the patch! I'll try to
understand whether there are use-cases that could cause these issues
in our case.

--

-- 
                                    Cheers, Roman Gareev.
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
jingu kang via llvm-dev | 25 Jun 08:52 2016

Question about VectorLegalizer::ExpandStore() with v4i1

Hi All,

I have a problem with VectorLegalizer::ExpandStore() with v4i1.

Let's see a example.

* LLVM IR
store <4 x i1> %edgeMask_for.body1314, <4 x i1>* %27

* SelectionDAG before vector legalization
ch = store<ST1[%16](align=4), trunc to v4i1> t0, t128, t32, undef:i64

* SelectionDAG after vector legalization
ch = store<ST1[%16](align=4), trunc to i1> t0, t133, t32, undef:i64
  t133: i32 = extract_vector_elt t128, Constant:i64<0>
ch = store<ST1[%16](align=4), trunc to i1> t0, t136, t32, undef:i64
  t136: i32 = extract_vector_elt t128, Constant:i64<1>
ch = store<ST1[%16](align=4), trunc to i1> t0, t139, t32, undef:i64
  t139: i32 = extract_vector_elt t128, Constant:i64<2>
ch = store<ST1[%16](align=4), trunc to i1> t0, t142, t32, undef:i64
  t142: i32 = extract_vector_elt t128, Constant:i64<3>

As you can see above SelectionDAG, if backend decides to expand vector
store with v4i1, vector legalizer generates 4 store with same
destination address. I think it needs to handle non-byte addressable
types like ExpandLoad(). When I look at ExpandLoad(), it handles the
case. If I implement new backend, I might have done custom lowering to
avoid this case. But I am using x86_64 target and it generates above
codes. How do you think about it? If I missed something, please let me
know.

Thanks,
JinGu Kang
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Strange opt result

Hi,
opt -O1 converts the attached test.ll to test_opt.ll.
"
opt --version
LLVM (http://llvm.org/):
  LLVM version 3.8.0
  DEBUG build with assertions.
  Built Jun 23 2016 (18:32:09).
  Default target: i686-pc-linux-gnu
  Host CPU: k8-sse3
"

test.ll:
"
; ModuleID = 'test.bc'

 <at> __mla__system.1 = global i32 0
 <at> 0 = internal global [12 x i8] zeroinitializer
 <at> 1 = internal global [8 x i8] zeroinitializer
 <at> 2 = internal constant [2 x i8] c"\0A\00"
 <at> 3 = internal constant [3 x i8] c"%u\00"
 <at> 4 = internal constant [5 x i8] c"%hhd\00"
 <at> 5 = internal constant [4 x i8] c"%hd\00"
 <at> 6 = internal constant [3 x i8] c"%d\00"
 <at> 7 = internal constant [5 x i8] c"%lld\00"
 <at> 8 = internal constant [3 x i8] c"%c\00"
 <at> 9 = internal constant [3 x i8] c"%s\00"
 <at> 10 = internal constant [3 x i8] c"%p\00"
 <at> 11 = internal constant [3 x i8] c"%e\00"

define internal [8 x i8]  <at> 12(i32, i8*) {
  %3 = alloca [8 x i8], i8 1
  %4 = alloca i32, i8 1
  %5 = alloca i8*, i8 1
  store i32 %0, i32* %4
  store i8* %1, i8** %5
  %6 = load i32, i32* %4
  %7 = bitcast [8 x i8]* %3 to i8*
  %8 = getelementptr inbounds i8, i8* %7, i8 0
  %9 = bitcast i8* %8 to i32*
  store i32 %6, i32* %9
  %10 = load i8*, i8** %5
  %11 = bitcast [8 x i8]* %3 to i8*
  %12 = getelementptr inbounds i8, i8* %11, i8 4
  %13 = bitcast i8* %12 to i8**
  store i8* %10, i8** %13
  %14 = load [8 x i8], [8 x i8]* %3
  ret [8 x i8] %14
}

define i32  <at> main() {
  %1 = bitcast i32 2 to i32
  %2 = bitcast [12 x i8]*  <at> 0 to i8*
  %3 = getelementptr inbounds i8, i8* %2, i8 0
  %4 = call [8 x i8]  <at> 12(i32 %1, i8* %3)
[...]
"

test_opt.ll:
"
; ModuleID = 'test_opt.bc'

 <at> __mla__system.1 = global i32 0
 <at> 0 = internal global [12 x i8] zeroinitializer
 <at> 1 = internal unnamed_addr global [8 x i8] zeroinitializer

; Function Attrs: norecurse nounwind readnone
define internal fastcc [8 x i8]  <at> 2() unnamed_addr #0 {
  ret [8 x i8] [i8 2, i8 0, i8 0, i8 0, i8 undef, i8 undef, i8 undef, i8 
undef]
}

; Function Attrs: norecurse nounwind
define i32  <at> main() #1 {
  %1 = tail call fastcc [8 x i8]  <at> 2()
  store [8 x i8] %1, [8 x i8]*  <at> 1, align 1
  %2 = load i8*, i8** bitcast (i8* getelementptr inbounds ([8 x i8], [8 x i8]* 
 <at> 1, i64 0, i64 4) to i8**), align 8
  %3 = icmp eq i8* %2, getelementptr inbounds ([12 x i8], [12 x i8]*  <at> 0, i64 
0, i64 0)
  br i1 %3, label %5, label %4

; <label>:4                                       ; preds = %0
  store i32 1, i32*  <at> __mla__system.1, align 4
  br label %5

; <label>:5                                       ; preds = %0, %4
  %6 = load i32, i32*  <at> __mla__system.1, align 4
  ret i32 %6
}

attributes #0 = { norecurse nounwind readnone }
attributes #1 = { norecurse nounwind }
"

which looks incorrect to me and returns 1 instead of the expected 0 at 
runtime. The testcase compiled without optimisation works as expected.
The input file has been produced with the MSElang compiler.

What is wrong?

Thanks, Martin
Attachment (test.ll): text/x-objcsrc, 2367 bytes
; ModuleID = 'test_opt.bc'

 <at> __mla__system.1 = global i32 0
 <at> 0 = internal global [12 x i8] zeroinitializer
 <at> 1 = internal unnamed_addr global [8 x i8] zeroinitializer

; Function Attrs: norecurse nounwind readnone
define internal fastcc [8 x i8]  <at> 2() unnamed_addr #0 {
  ret [8 x i8] [i8 2, i8 0, i8 0, i8 0, i8 undef, i8 undef, i8 undef, i8 undef]
}

; Function Attrs: norecurse nounwind
define i32  <at> main() #1 {
  %1 = tail call fastcc [8 x i8]  <at> 2()
  store [8 x i8] %1, [8 x i8]*  <at> 1, align 1
  %2 = load i8*, i8** bitcast (i8* getelementptr inbounds ([8 x i8], [8 x i8]*  <at> 1, i64 0, i64 4) to i8**), align 8
  %3 = icmp eq i8* %2, getelementptr inbounds ([12 x i8], [12 x i8]*  <at> 0, i64 0, i64 0)
  br i1 %3, label %5, label %4

; <label>:4                                       ; preds = %0
  store i32 1, i32*  <at> __mla__system.1, align 4
  br label %5

; <label>:5                                       ; preds = %0, %4
  %6 = load i32, i32*  <at> __mla__system.1, align 4
  ret i32 %6
}

attributes #0 = { norecurse nounwind readnone }
attributes #1 = { norecurse nounwind }
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Roman Gareev via llvm-dev | 24 Jun 14:04 2016

Application of a piecewise quasi-affine transformation to a band node

Dear Sven,

if I'm not mistaken, according to our discussion on reviews.llvm.org,
application of a piecewise quasi-affine transformation to a band node
isn't available yet in the public repo, because there are open
questions about design decisions.

Could you please advise me where I can find it's current
implementation and information about these open questions?

--

-- 
                                    Cheers, Roman Gareev.
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Daniel Sanders via llvm-dev | 24 Jun 12:02 2016

Representing MIPS ABI information in the triple as ARM/X86 do for EABI/EABIHF/X32

Hi,

Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS
N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also
enabling it for the N32 ABI because this information is not reflected in the triple and that's the only
information MipsMCAsmInfo has. This would be fine if it N32 was also in a good state but the current N32 ABI
support for IAS is badly broken and will likely take considerable effort to fix (and fixing it also
requires solving the same key problem as enabling IAS for just N64). I therefore want to separate the two
ABI's so that I can finish off N64 and then fix N32 afterwards.

I've posted a series of patches that allow us to distinguish N32 and N64 so that we can enable IAS for only N64 
(D21465, D21467, D21069 for LLVM along with D21070, D21072 for clang). During the review of D21467,
Rafael asked me to explain my approach here. I'm hoping that people will agree that this is an acceptable
approach to take and that it's no different from how other targets handle certain ABI's and how we already
handle -m32/-m64/-EL/-EB/etc.

The approach I'm using is to encode the ABI information into the triple in the same way that ARM does for EABI
and hardfloat, and the same way that X86 does for X32. These targets define variants of Triple::GNU for
each of these ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and Triple::GNUX32 values of
the environment component of the triple and it's up to the frontend and/or API-user to pass the right thing
to the backend.

For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these
are supported by tools like binutils (by virtue of a wildcard match '*linux-gnu*') and of these three,
Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by Debian if/when we do an N32
port, and Triple::GNUABI64 is currently used by Debian for our N64 port. Once the ABI is in our backend
triples, it can be used by MipsMCAsmInfo to enable IAS by default for N64 without also enabling it for N32.
In later patches, such as D1292 this same information will also be used to fix the N32 support for IAS.

At this point, you may be wondering what happens to Triple::GNU for triples like mips-linux-gnu and
mips64-linux-gnu. The answer to this is that the API-user (e.g. clang) is expected to normalize such
triples down to one of Triple::GNUABI32/GNUABIN32/GNUABI64. This can be as simple as adding:
  Triple ABITriple = TT.getABIVariant(ABIName); // ABIName can be the empty string to get the default ABI.
  if (ABITriple.getArch() != Triple::UnknownArch) {
    TT = ABITriple;
    ABIName = ""; // <- Only needed if this would end up in MCTargetOptions::ABIName.
  }
to the appropriate place in the caller. This is the same way clang handles the -m32, -m64, -EL, and -EB
options with those options using get32BitArchVariant(), get64BitArchVariant(),
getLittleEndianArchVariant(), and getBigEndianArchVariant() respectively to transform the triple
for the backend.

In summary, human end users of tools such as clang will continue using the same triples as they always have.
These tools will then resolve them down to the effective triple (for example, in functions like clang's
ComputeEffectiveClangTriple(), ComputeLLVMTriple(), and computeTargetTriple()). The MIPS
backend will only see the triples that have a specific known ABI. I'd like to stress that this process is the
same as the one we already use today for other options. For example 'x86_64-linux-gnu-clang -m32'
transforms the triple with get32BitArchVariant() and passes 'i386-linux-gnu' to the backend.

So far I've only been talking about Linux/GNU but the patch series also covers Linux/Musl, Linux/Android,
and FreeBSD. I haven't talked about those because they are handled in the same way as the Linux/GNU case
described above except that they use Triple::ABI32/ABIN32/ABI64 (or Android32/Android64 in the case
of Android) instead of Triple::GNUABI32/GNUABIN32/GNUABI64.

Why is the Triple approach better for MIPS than MCTargetOptions::ABIName?
=========================================================================

A major pragmatic reason is that it works today and the MCTargetOption::ABIName approach doesn't. It's
also in keeping with other targets whereas until fairly recently MIPS was the sole user of
MCTargetOptions::ABIName. There is currently a single PowerPC test and six ARM tests that use the
-target-abi option that feeds MCTargetOptions::ABIName at the moment and both of these targets are only
using it for relatively minor tweaks to the ABI.

As things are today, MCTargetOptions::ABIName is good at fairly small tweaks to the ABI such as calling
convention changes but it's unable to deal with more fundamental changes such as selecting between
ELFCLASS32/ELFCLASS64 or enabling IAS. Some of these limitations look fixable if given months-years of
effort but I can see potential problems once the obvious plumbing problem is fixed. Some of these problems
such as preventing the linking of incompatible IR files in the IRLinker would require me to represent the
ABI in the LLVM-IR (it's currently handled solely by the triple) which has been strongly opposed in
earlier discussions about triples. 

I can provide more detail on some of the specific problems if required but this boils down to a choice between
an easy paved road that other people use and that I know will end in a working state, or an unexplored path
with known difficulties and an uncertain result.
_______________________________________________
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Gmane